• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Mechanics of changing passwords using regular validation system
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mechanics of changing passwords using regular validation system


  • Subject: Re: Mechanics of changing passwords using regular validation system
  • From: Paul Hoadley <email@hidden>
  • Date: Thu, 26 Feb 2015 07:54:27 +1030

Hi Chuck,

On 26 Feb 2015, at 3:01 am, Chuck Hill <email@hidden> wrote:


What I'd like is for it all to be part of the validation system, such that when saveChanges() is called, validateForSave() throws appropriate exceptions and messages could be sent to the view layer.  But it's a bit hairy.  Consider just setPlaintextPassword().  Say the supplied string is too short and it fails the password length test.  My naive solution was to create the ValidationException, but hang onto it until saveChanges() is called

If the value is not valid, the validatePlaintextPassword method MUST throw at that point.  What usually happens (e.g. When takeValues is processed on an HTML page, is that validatePlaintextPassword() is called and then  setPlaintextPassword() if it does not throw.  If the value is not valid, the validatePlaintextPassword method MUST throw at that point.  If you want the validations to work you must change the value, valid or not.

Ah OK, I wasn't even implementing validatePlaintextPassword()—it didn't occur to me because 'plaintextPassword' is not a model attribute, and I'm also not keeping the plaintext password (obviously).  In fact, to implement that I _would_ have to hold the plaintext password, at least in memory, and now this is all starting to sound like a security risk, albeit fairly theoretical.

—but, and you can see where this is leading, validateForSave() doesn't get called unless the password is actually changed (assuming nothing else on the User is changed), so I don't get to throw that exception I stashed earlier.  In that case I might be able to make the change to the too-short string, and do what I was planning, but the changePassword() method is another story.

Say changePassword() is called, but oldPassword doesn't hash correctly.  Now what?  Do I call setPlaintextPassword(newPassword) anyway to ensure validateForSave() is called?  But then in that method, I throw the exception I stashed, sure, but the password has now _changed_ even though the app reports it _hasn't_.  So a subsequent call to changePassword() with the previous oldPassword value is going to fail.  Again, naively, I considered maybe changing it _back_ to the snapshot value for that attribute in validateForSave() before throwing the exception, but then BAM!  EOF Commandment #4:

Don't modify any EO properties in validateFor...(...) methods

So I'm stumped.  Does this sound possible, or should I give up and continue to handle this kind of thing outside the regular validation system?
That is probably your best bet, or have changePassword throw validation exceptions, and accumulate them and any from takeValues in the GUI layer.  That way you don’t even call saveChanges() if things have not validated to that point.  My presentation from WOWODC 2009 might give you some ideas.  No, of course I never finished it!  
http://sourceforge.net/projects/wovng/
There are no files, you have to clone the repository.

Thanks Chuck.  I think if the question I was asking in my original post was "Is this kind of thing a reasonable candidate for handling entirely within the model?" then the answer is "No."


-- 
Paul Hoadley
http://logicsquad.net/


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Mechanics of changing passwords using regular validation system (From: Paul Hoadley <email@hidden>)
 >Re: Mechanics of changing passwords using regular validation system (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: ERCoreBusinessLogic preferences??
  • Next by Date: Re: Mechanics of changing passwords using regular validation system
  • Previous by thread: Re: Mechanics of changing passwords using regular validation system
  • Next by thread: Re: Mechanics of changing passwords using regular validation system
  • Index(es):
    • Date
    • Thread