Victor Engmark wrote:
> Davi Leal wrote:
> > Victor Engmark wrote:
> > > For users to be able to detect their error after the fact, we could
> > > let the email stay in the field after submission.
> >
> > Good point.
>
> Actually, it would probably be even better to redirect the user to the front
> / login page, since that's where they would logically be going afterwards.
> We could display a prominent message to confirm that we did something.
> Modified the task accordingly.
When the user goes to the Lost password page, what he/she wants to do is
be able to log in.
After we process his/her lost-password-request, and show the prominent
message "You should receive an email with ...", he/she is ready to use
the omnipresent :) login box, under the menu, to log in.
So I think there is not need to do a redirect.
I'd still argue that the "lost password" page is the least useful
place the user can be after submitting a request. Since we don't have a separate login page, the front page is probably the most useful at that moment.
> > > To stop pranksters and accidental double-clicks from annoying users,
> > > we could also add a restriction that no email will be sent if an
> > > email was sent to the same address less than X seconds / minutes
> > > before. We should probably change the message to reflect that, to
> > > avoid even a white lie (ref. "your email will arrive shortly").
> >
> > This extra addition requires we create a new field at the E1_Entities
> > table to save the last lost-password-request time stamp. But with the
> > current data base model, we can only do it for the emails (entities) which
> > are already registered. So the spammers could note what email exists doing
> > several quick requests.
>
> No, because we won't tell them whether an email was actually sent or not.
> I'm thinking about having something like the following as the message for
> the user:
> You should receive an email with your (new?) password shortly. For security
> and privacy reasons, we'll only send to addresses registered at GNU Herds,
> and maximum once per X minutes.
OK, now I agree with you. So we will have to add a new field at the
E1_Entities table to save the last lost-password time stamp, for example:
E1_AbuseLastTime
We could use that field to, to combat abuse at the login box. Do you
agree? Do you have a better field name?
Why "E1_"? Anyway, I'd call it LastPasswordRetrieval or just PasswordRetrieval (less clear). Separates the information from the function(s), which could be several.