Auto-registration without "Optimistic Saving"

[Empact]

The docs say:

WARNING: if you are using auto-registration, any fields you map should NOT have constraints enforced at the database level. Authlogic_rpx will optimistically attempt to save the user record during registration, and violating a database constraint will cause the authentication/registration to fail.

However, looking at the code it seems possible that a more general auto-registration feature could be built for Authlogic, which doesn't save bad data to the db (e.g. violating uniqueness constraints on username and such).

I'm going to look into this for my own sake, but would appreciate your thoughts if you have any opinion on the matter.

[tardate]

It is a bit knobly. If you have better suggestions, would be really interested to hear.

Here are a few notes to explain the current approach.

The basic problem is that the authentication takes place in phases.

When we receive the callback from rpxnow - assuming it was "success" - authlogic_rpx wants to establish an authenticated session.

If at this point, the profile information returned from rpx doesn't meet the application's validity requirements (e.g. username not unique ) then we have a dilemma.

If the unique username constraint is implemented at the database level, then authlogic cannot create the user. The contraint will be violated, authlogic login will fail, and the user's login will be rejected.

The approach I've taken with authlogic_rpx is to recommend basically this (if you want to have auto-registration):

• any profile information you want to save from rpx in the user model should not be validated by database constraints (to avoid the login failure lockout)
• enforce any validations needed in the model. This will allow users to register/login, but their profile will have "validation errors" that the user will have a chance to fix
• If you want to get more sophisticated, I think the best approach is to save the additional profile information outside of the user model itself to avoid tripping up authlogic.

If you don't want auto-registration, then this is all moot. However, I personally think auto-registration is one of the big benefits that rpx can let you deliver to your users.

[Empact]

I think I've got it, as of last night. I'll put together a fork of the rails example app adjusted to work with my changes. The basic flow is this:

• The session validates its user on save. In a world where auto-registration doesn't exist, this isn't necessary as all existing users are assumed valid
• In the case where auto-registration takes place and a user validation is violated, the session will fail to save; the Sessions controller can pre-emotively run #registration_incomplete? prior to #save in the create action to have the session run validations on the session and catch this case, rather than failing generically
• In this case, render a form which includes the existing user data and validation error, along with the controller's params to pass-through back to the same controller action.
• The user corrects the error and re-submits, and authlogic_rpx defers to the submitted user attributes via the new_rpx_user hook. If the new params + rpx response is valid, they're registered, if no they're returned to the same form with the new validation errors.

The big win being that this keeps our dbs clean and constrainable.

Any thoughts on this approach? I'll have the example together tonight.

[tardate]

Great! Look forward to going through it when you've pushed the fork

[Empact]

Alright, I have the fixes up at:
http://github.com/Empact/authlogic_rpx
http://github.com/Empact/rails-authlogic-rpx-sample

One change which ought to be scrutinized & discussed is that it was necessary to monkey-patch authlogic to remove the save_record call from Session#valid? http://github.com/Empact/authlogic_rpx/commit/91b3faa18d280a63229d271691615be0b6703aeb

There may be good alternatives to this. For example, changing calls to save_without_session_management to not pass false (and by doing so, to respect validation errors).

[tardate]

Thanks for the patch! I've been a bit busy to check it out so far, but this weekend hopefully..

[Empact]

I'm still unsure about the authlogic valid? monkey patch. We should look at how the authlogic_openid plugin handles auto-reg, as I believe it has binarylogic's involvement.