Need to be able to store some context before sending to the provider

[sontek]

I would to allow about registration and authentication via social networks but want to handle what happens when it comes back differently.

There is no way to currently know where the auth was initiated.

[kiall]

I would love to see this implemented - if there is a chance of it being merged, I can likely create a pull...

@bbangert thoughts?

[jayd3e]

There is a different context for each provider(FacebookAuthenticationComplete, TwitterAuthenticationComplete, etc.), so you can attach different Pyramid views to different contexts, if you are using velruse as a Pyramid plugin. Something like:

    @view_config(context='velruse.FacebookAuthenticationComplete'..)
    def view(request):
         pass

[kiall]

@jayd3e - I think we are talking about different kinds of context...

I need to be able to store arbitrary data before redirecting the user, and then receive it when the user arrives back.

I'm suggesting support for, for example, OAuth2's 'state' parameter described in section 4.1.1 of the OAuth2 spec.

[jayd3e]

Gotcha. Yah, in my apps I would likely store that kind of information in the session, and then remove those variables once authentication is complete. I'll have to take a look at OAuth2's 'state' parameter though, as it would be nice if velruse supported the full spec.

[mmerickel]

Velruse would probably store this information in the session. It tends to use the state parameter for CSRF checks to validate the authentication. With that in mind, I'm not sure how much velruse should do here versus you just storing the data in the session before redirecting to the velruse login endpoint. Thoughts?

[mmerickel]

FWIW this is similar to #55

[naktinis]

I'm using velruse as a Pyramid app. In the old velruse, it was very convenient to pass endpoint as a parameter which is POSTed to velruse provider form handler. Later, when velruse receives the response from provider, it would redirect to the endpoint given as the parameter during the first POST.

That being said, one option for the new velruse providers would be to take some "context" parameter during the initial POST. Save it to session under uuid-like key that is received from the provider as the "state" parameter (so as to allow for simultaneous auth transactions). And then in auth_complete_view take the "context" from session and pass it to the endpoint url.

Would that work? Does anyone have better options in mind?

[naktinis]

Of course, overriding the endpoint (that is now taken from config) for an individual form would also be nice.

[mmerickel]

I had not considered simultaneous auth transactions for a single user to be a priority.

[mmerickel]

@sontek What do you think about just adding a user_data parameter to the login forms. This would update the authentication context to contain profile, credentials, and user_data. This parameter could be anything you want it to be. A json-encoded string, encrypted, signed, whatever. To velruse it'll just be a key shuffled around. I'm not sure user_data is a good name, maybe custom_state?

[mmerickel]

Another option is to hook into Pyramid's event system. Basically when the login view is invoked it could emit an event containing the request, the provider name/type and give you a chance to store information in the session.

[naktinis]

I guess something like user_data in login forms would work for me.

[naktinis]

@sontek would the solution proposed by @mmerickel work for you? Do you have other ideas?

[sontek]

@mmerickel @naktinis This would work for me.