How to: Password change use case (or any property change requiring confirmation)

How to: Password change use case (or any property change requiring confirmation)

Old forum URL: forums.lhotka.net/forums/t/5181.aspx


rsbaker0 posted on Thursday, July 31, 2008

How do the CSLA veterans handle this particular use case?

I'm editing a user profile (in an ERLB), and there is a edit field for the password. If I change the password, I need to be prompted to confirm the password change before the object is saved.   (Moreover, the actual stored password might need to be encrypted, etc., but that's a side issue).

The more general form of this scenario (and we have 5-10 of these in our application) is that a user has made a data change that requires additional data not displayed in the grid or original screen to be supplied via a secondary prompt screen before the data is saved.

The obvious possibility is to actually not allow direct entry of any such field and provide a specific function for making the change that presents a screen with all the needed data, but I hoping to find a good pattern for handling this scenario in general that would not require this restriction.

Another thought would be to (1) have some sort of event that the UI could hook to catch the property change, coupled with (2) some sort of validation rule that renders the object invalid until the additional data is supplied. For the user scenario above, a user object with a changed password value is invalid unless a password change confirmation has also been provided to the same user object, or something similar. In our case, we actually have a "Password Changer" BO that validates the password hasn't been reused, meets complexity requirements, sets the expiration date in the user, logs the password change operation, etc., so it occurred to me to just attach such an object as a child to the user object, and the user object will save it as part of it's own processing.

Other ideas welcome...

ajj3085 replied on Thursday, July 31, 2008

Well, my view is that prompting is a purely UI thing, so if you need a prompt, the UI should be built to do it.  The BO shouldn't care, it should assume the UI is communicating with the user properly.

As for secondary information, I have some places where if for example a value on the BO is true, another field MUST be entered.  That's a business rule, so the BO has a rule to enforce this.  The UI's job is to let the user know about the broken rule.  The BO can help out the UI to some extent; for example, if the box isn't checked, CanWriteProperty can return false for the secondary fields.  But if you have a rule that those fields must be empty, you may need to blank the other fields automatically.  So in that case, it really depends on what you want to do.

HTH
Andy

rsbaker0 replied on Thursday, July 31, 2008

ajj3085:
Well, my view is that prompting is a purely UI thing, so if you need a prompt, the UI should be built to do it.

I completely agree -- the problem is I don't know what the best way to build such a UI thingy is.

For the sake of discussion, say you have the password in a grid in the ERLB.

The user types in new password, then immediately clicks on the next row. ApplyEdit gets called on the user object and ERLB will try to save it.

How do you get the opportunity (or what is the best way) to prompt the user after the password change is detected but before an attempt is made to save the object?

ajj3085 replied on Thursday, July 31, 2008

If the grid supports it, you could listen for the grids BeforeExitEdit (which is how you'd do it using the Infragistics WinGrid).  Other grids may or may not support a similar concept.  If you're using .Net 3.5 / Csla 3.5, you might be able to extend BusinessBase to implement IPropertyChanging.  I'm not 100% sure about that scenario though, because I've not gotten to look at providing my own IPropertyInfo implementation... but you could look at that, and see if you can't add behavior that way.

rsbaker0 replied on Thursday, July 31, 2008

OK, I have a running prototype, but I'm not so sure about it as a general model.

(1) My "user" BO has a static event that it fires when a new password value has been supplied. This is just a helper for a UI, and avoids serialization issues.

(2) I haven't done a the grid yet, but my user form subscribes to the password changed event

(3) When password change occurs, the event handler in the user form inspects the sender to see if it is a reference to the same object being edited, if so, it constructs a PasswordChanger and displays a "Confirm Password Change" screen bound to the PasswordChanger.

(4) If the change is successfully confirmed, then the PasswordChanger is provided to the user object (otherwise, the original value of the password is put back).

(5) When the user object is Saved(), it applies the data from the PasswordChanger as part of its database update (encrypts user-supplied value, sets password expiration date, logs password change in separate table, etc.)

The user BO logic doesn't require this particular UI model, it just requires that a PasswordChanger accompany any password change.

Again, I'm new at this, so I'm not sure what perils are hidden in this approach.

Copyright (c) Marimer LLC