0

I have a requirement in my PHP application - to allow a user to reset their password. The process is as follows:

  1. User requests password reset;
  2. User enters email address;
  3. System validates email address - if invalid tells user and process ends, else an email is sent to the entered email address containing a hashed token in a link;
  4. User clicks link in email;
  5. System receives reset request with token embedded - validates the token and time limit (60 mins);
  6. if reset request is valid, a reset password view is displayed with two password fields, else user told the request is invalid and the process exits;
  7. Assuming valid request, the user enters their password twice which are then validated by a comparison.

This seems to be current best practice.

My question is how this is achieved using MVC. I have a front controller which sucks in data from GET and POST requests, and passes the data on to the relevant view-model and view through a router class.

Using this model, I have a reset-password view-model and view that takes care of the user's email input and the email to the address with the linked token - all good here.

I also have a view-model and view for the user to enter their new password. It is here I am having issues. This validates the incoming token and time limit - this is working. Then, if the token and time limit are valid it presents the user with the set-password view, which needs to be validated. I have not been able to come up with a solution using the set-password view-model and view that allows me to present the set password view AND validates, presenting the user the reasons for the passwords not being valid (either of the password fields are empty, or passwords do not match).

I hope I have been clear with my issue. Could someone suggest a best practice solution to my issue that addresses the process please? I am thinking I am doing too much in the second part of the process - breaking up the work and introducing a new view-model (invisible to the user) to take care of the token and time validation before passing on to the set-password part is one solution I am looking at, but it feels wrong. It doesn't have the aethestic appeal my incorrect solution has (less is good).

Steve Cooke
  • 447
  • 1
  • 4
  • 14
  • What exactly is your question? And, btw, [front controller](http://www.martinfowler.com/eaaCatalog/frontController.html) pattern is unrelated to MVC .. which means that your descriptions makes no sense. Also, what the hell is "set-password view-model"?! – tereško Feb 04 '14 at 08:15
  • My understanding of MVC, at least as it applies to a web-based application, is that the model specifically provides data to the view to display - the view asks for the data from the model. That's about all it does - provide data according to the business rules. I also have a data access layer that uses a 'model' (I don't know the correct terminology for this object) that provides access to the data layer. The object I call a view-model communicates with the data access 'model' to retrieve the data the view requires. To differentiate the objects, I call the model used by the view a view-model – Steve Cooke Feb 04 '14 at 10:44
  • Secondly, while my front controller handles all the requests, it delegates the work to my MVC implementation through a router. The front controller knows which MVC triad to create through the requested action. – Steve Cooke Feb 04 '14 at 10:54

1 Answers1

0

@_teresko - Thank you. My issue is with my incorrect understanding and implementation of MVC. I have read further, and particularly here. Your comments have forced me to revisit my application process, and I have found the issue. A thin controller is sometimes not the best solution.

Community
  • 1
  • 1
Steve Cooke
  • 447
  • 1
  • 4
  • 14