Marlowe announced the presence of a new API to reset passwords.
I implemented this API, and I must say I’m pretty disappointed that this is the API about which the community has been asking for, for well over a year now.
Here are my issues (upper case isn’t me shouting :), it’s me providing emphasis):
EVERY SINGLE request around this issue talked about the need to be able to customize the email that gets sent. I really don’t want a Wix branded email sent to my customers for something as fundamental as password reset. I want my own branded email used - why have I paid the premium subscription to have all the Wix branded stuff removed from my website only to have it show up again on something as basic as a password reset?
Why would I want a password reset email to say: " Questions? Visit Wix Support "? I want my customers coming to ME for support!
Why does the title say “Forgot your password?”? There are many other reasons someone might want to reset a password other than they forgot it. Sure, this might be the most common, but again, WE NEED THE ABILITY TO CUSTOMIZE THE MESSAGE!
Clicking the “Reset Password” button takes me to another Wix branded page that contains the hint to log into Wix. My customers are now further confused - “why am I being prompted to log into Wix? What is Wix?” We should be able to designate our own custom landing page that we can brand appropriately.
There should really be TWO MAJOR ADJUSTMENTS to this API:
The web-based API approach (i.e. causing a web page to be launched which explains what is going on, what the user needs to do, having a web based landing page to enter the new password, etc.) needs to support custom pages and a customized email, if the Wix website owner has provided them. The fallback can be what it is now.
There needs to be a completely API driven approach for users that either don’t want a web based one, or want an additional experience to the web based one. For example, my mobile app users don’t need or want to have a web page launch to change their password, they would like it to be handled in the app (with a launch of their email reader if they need to click on a link in the email). Why can I not completely handle this in a communication back and forth from my back-end functions to my mobile app?
I won’t be implementing this API any time soon. It is simply not a good user experience.
I’m happy to volunteer to help out in the planning/testing stages of future changes to this API. I simply can’t believe most users will accept this as a proper way to provide password reset - even those customers that have a website only and aren’t concerned about a native mobile app.
In other news, it seems there are some serious back-end issues going on. I got validation it wasn’t just something we did when we implemented the new API, see this post .
Hey there,
I’m Or from the product team. Thanks a lot for the detailed and valuable feedback. It really helps us to further improve.
Regarding your feedback - there is a confusion about the flow I must explain:
ONLY for Site Members that are also site collaborators (AKA “Admins”), since they have a connected Wix account, they use their Wix account password in order access the website. In those cases (and probably for your case when testing the new API), we trigger the Wix account password reset flow.
BUT, for regular Members, we send an email on your site’s behalf, obviously without ever mentioning Wix or our support, or any link to a reset password at Wix. Please check it out again with a regular Site Member.
We are planning on allowing you customize this email as well - I can’t disclose the exact timeline, but we are already working on it.
We completely understand the need to fully customize your users’ experience, and we invest a lot of efforts into it - in the past year we released the option to customize the site login, and the 'Member approved" email - and as I mentioned we will continue our work on allowing you customize it all - emails and pages alike.
Thanks Or, I’ll try it out with a different user as soon as the other back-end collection issues that I and others are experiencing right now are addressed.
Btw your comments addressed the first part of my suggested changes. What about the second part? Can we augment this API flow to have a completely programmatical two factor authentication for the reset? I am already doing this now for site registration - you could use that as a model. In my mobile app I can programmatically:
Receive the user’s email address and password in through a back-end function.
The back-end programmatically registers the user, but since I have the site configured for manual approval that user is in ‘pending’ state.
An email is automatically generated that includes a newly generated 6 digit key. The user must check their email, then enter the key back into the mobile app, which calls a separate ‘validate registration code’ backend function.
This validation then calls ‘approveByToken’ to finalize the registration, set them up in my collections appropriately, etc.
All this works well, and I never have to pop a web page to my mobile user. That is the same type of experience I’d expect for password reset.
Hopefully, since Wix already supports this for something as fundamental as site registration, they can do so for password reset.
The email is pretty plain, but at least it does appear to come from my domain and doesn’t mention Wix anywhere, and ditto with the web page that appears after clicking the “Create New Password” link, so thanks for that!
I look forward to comments about my suggestions for a back-end only approach to password reset similar to the registration flow I outlined, which doesn’t require web pages.
Regarding having API to enable a custom flow for reset password - it certainly make sense. If your’e willing to, it would be great to further discuss it with you.
I would be more than happy to brainstorm on an API to enable a custom flow for reset password. I am on Mountain time in the US, and regularly communicate with colleagues in Israel so if that is where your product team is I’m happy to schedule an early morning my time Zoom or some such to discuss.
Generally speaking Mon/Wed/Fri mornings for me are flexible.
Or,
Please know that I have logged a support ticket about the way the email is sent to our members. The from email address is identified as spam an our members, who have corporate email servers, NEVER receive the reset password email at all! It isn’t in their spam folder, it isn’t in quarantine - it NEVER makes it to the member which renders the members account UNUSABLE!
This is a HUGE problem for us and I have been waiting for a while now for some kind of response on my support ticket but have heard nothing.
I suggested that IF the password reset email was sent in the same way that triggered emails are sent, that would most likely solve the issue for us as those emails show as coming from our domain rather than site-members.com.
It is the site-members.com that is identified as spam and completely blocked!
Please HELP! This is an urgent issue.
The support ticket number is 1830766892
Thank you.