Thinking a bit more an Authentication object doing the password stuff makes sense too.
I'm determined that I'm not going to shove it in a service though ... don't send me back to fatserviceland On Oct 22, 5:50 pm, Alan Livie <[EMAIL PROTECTED]> wrote: > @Brian. I don't know if password strength would be a 'cross-cutting concern' > as it only applies to a small number of classes - Users mainly. > > Brian Kotek commented somewhere recently on a UPS parcel object that knew how > to reach its destination - basing the journey on cost, time factors etc. > If a UPS object is doing all this surely our humble User should be able to > check his/her password is strong? > > I do accept though that checking that newPassword equals confirmNewPassword > MAY be something that lives outside a User. > But again, just because we don't persist the 'confirmNewPassword' who's to > say that it shouldn't live in the Model because all View's would probably > implement a password change in the same way (ie have existing, new and a > confirm field) > > Alan > > ----- Original Message ---- > From: Brian Sadler <[EMAIL PROTECTED]> > To: CFCDev <[email protected]> > Sent: Wednesday, October 22, 2008 5:04:56 PM > Subject: [CFCDEV] Re: User password changes and OO confusion > > Hi Alan, > > I agree with Tom that option c is definitely the best one of the > three. The User object has one (and only one) password, it doesn't > make sense for it to have a newPassword, or confirmPassword fields as > well. > > Also I think Michael had a very valid point about the actual logic to > validate the password change being in a Password / Authentication > object as opposed to the User object. However the route to actually > calling that might be quite long – UserService.updatePassword() calls > User.updatePassword() which delegates to > Authentication.validatePasswordChange() etc. > > It also throws up the question of what you’re using the service layer > for because to my mind, people are using service layers in two > different ways: firstly, there’s the service layer as a facade for > coarse grained access to the model, and secondly there’s the AOP > approach of a service layer component providing services to the model > – I think “cross cutting concerns” is the appropriate phrase. > Security functions –isAdministrator(), decryptPassword() and > validateNewPassword() seem to me to be typical cross-cutting services > that you would provide to potentially many components in the model. > > So whilst I entirely agree with your point about not wanting to have > anaemic domain models with all the logic stuffed in the service layer > (facade) I think in this case the service layer (AOP/cross cutter) is > the appropriate place for making sure new password is of sufficient > length, complexity etc. etc. > > On Oct 20, 6:15 pm, Alan Livie <[EMAIL PROTECTED]> wrote: > > @Paul, @Matt - thanks for this. Nice approaches. I see the cloning gets > > around the problem previously posted on this group about the session user > > in an invalid state. > > > Thanks > > > Alan > > > ----- Original Message ---- > > From: Paul Marcotte <[EMAIL PROTECTED]> > > To: [email protected] > > Sent: Monday, October 20, 2008 5:53:04 PM > > Subject: [CFCDEV] Re: User password changes and OO confusion > > > I'm with Matt on this. In fact I just wrote this up last night. Consider > > it a variation on a theme... > > > <cffunction name="changePassword" access="public" output="false" > > returntype="any"> > > <cfset var user = getCurrentUser().clone()> > > <cfset var result = getTransientFactory().create("ServiceResult")> > > <cfset var errors = StructNew()> > > <cfif hash(arguments.currentPassword) is user.getPassword()> > > <cfset > > result.setErrors(user.populate(argumentCollection=arguments))> > > <cfif (result.getSuccess())> > > <cfset result.setErrors(user.validate("changePassword"))> > > <cfif (result.getSuccess())> > > <cfset user = getUserGateway().save(user)> > > </cfif> > > </cfif> > > <cfelse> > > <cfset errors['badCredentials'] = "Password invalid."> > > <cfset result.setErrors(errors)> > > </cfif> > > <cfset result.setResult(user)> > > <cfreturn result> > > </cffunction> > > > On Mon, Oct 20, 2008 at 9:45 AM, Matt Quackenbush <[EMAIL PROTECTED]> wrote: > > > In my humble opinion, the User absolutely **should** know how to validate > > itself, including validating a new password. Otherwise, exactly as you've > > suggested, you end up with a bunch of bloated structs called CFCs floating > > around your application. > > > Like anything, there is more than one way to skin a cat, but here's a bit > > of pseudo code from my controller that shows how I handle a password change. > > > user = getSecurityService().getSessionUser(); > > if ( user.isPassword( event.getValue("currentPassword") ) { > > clone = user.clone(); > > clone.setPassword( event.getValue("password") ); > > clone.setConfirmPassword( event.getValue("confirmPassword") ); > > > if ( clone.validate( context: "change password" ) { > > clone.save(); > > } else { > > // send them back to the form with validation error message(s) > > } > > } > > > HTH > > > On Mon, Oct 20, 2008 at 10:26 AM, Alan Livie <[EMAIL PROTECTED]> wrote: > > > I keep falling into the 'anemic domain model' trap and for once I want this > > User to be a genius :-) I have too many simple beans with dumb getters and > > setters and service methods with all the good stuff. > > It must end! > > > As far as my User goes, it can be in an invalid state until the save() > > method calls validate() before persisting the data if validation passes. So > > the User can have an invalid email address until validate() is called. > > > Alan > > > -- > > Paul Marcotte > > Fancy Bread - in the heart or in the head?http://www.fancybread.com > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection > > aroundhttp://mail.yahoo.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
