How to receive json parameters correctly?

[disburden]

This is the routing method for post_authorize in the example code

async fn post_authorize(
    (r, req, state): (HttpRequest, OAuthRequest, web::Data<Addr<State>>), ) -> Result<OAuthResponse, WebError> {
) -> Result<OAuthResponse, WebError> {
    state
        .send(Authorize(req).wrap(Extras::AuthPost(r.query_string().to_owned())))
        .await?
}

The second parameter req is an OAuthRequest object, if I want to receive the json parameter uploaded by the client I have to change the type of this parameter to web::Json, then I lose the OAuthRequest object and can't do the subsequent operations.
How can I receive the json parameter correctly or can I manually create an OAuthRequest object in this method using the OAuthRequest::new() method to perform the subsequent operations.
Thank you!!!

[urkle]

Currently, you'd have to take your JSON inbound params and then create a OAuthRequest to pass onto the other layers.

(I'm working on this same issue now). It would be nice if the contract were a little looser on the authorization_code phase since that is not as strictly defined in the spec.. Only the initial "get" input and the redirect back.

So, what I am doing right now is building a VueJS front-end for my "authorize" page.. Thus VueJS handles processing the GET arguments and converting it to an authorization code POST to drive the rest of the process.

This is what I ended up doing to handle that

(this is for Poem, but should be similar for your use-case as well)

#[handler]
pub async fn authorize_handler(
    data: Json<AuthorizeData>,
    provider: Data<&OAuthProviderType>,
) -> poem::Result<Response> {
    use poem::{FromRequest, IntoResponse};

    let mut url = Url::parse("http://localhost/").unwrap();
    {
        let mut query_builder = url.query_pairs_mut();
        if let Some(ref client_id) = data.client_id {
            query_builder.append_pair("client_id", client_id.as_str());
        }
        if let Some(ref response_type) = data.response_type {
            query_builder.append_pair("response_type", response_type.as_str());
        }
        if let Some(ref redirect_uri) = data.redirect_uri {
            query_builder.append_pair("redirect_uri", redirect_uri.as_str());
        }
        if let Some(ref state) = data.state {
            query_builder.append_pair("state", state.as_str());
        }
        if let Some(ref scope) = data.scope {
            query_builder.append_pair("scope", scope.as_str());
        }
        if let Some(ref decision) = data.decision {
            query_builder.append_pair("decision", decision.as_str());
        }
    }

    // build a URI object to pass into Poems request builder. Other frameworks will have a different means to do this.
    let uri: Uri = url.as_str().parse().unwrap();
    let req = poem::Request::builder().uri(uri).finish();
    // Now convert my frameworks' request to the OAuthRequest
    let request = OAuthRequest::from_request_without_body(&req).await?;

    // now do the authorization flow
    provider
        .with_solicitor(AuthorizeSolicitor)
        .authorization_flow()
        .execute(request)
        .map_err(|e| {
            ...
        })
}

[disburden]

It seems a bit strange, but as long as it can be used.
I'll try it out for a while. Thank you very much! @urkle

[urkle]

@disburden the only change you'll need to also make is ensuring you are processing any credentials for your user so that you know WHO is logged in currently.

I'm probably going to start a PR to rework how the authorization_flow code is done so that it is a little more flexible in terms of use and can accomidate different UI/UX designs than just the simple GET form that POSTS. (so we can gain some code-reuse of the processing behind the scenes)

[197g]

A note, instead of building an instance of in your framework's Request type just to satisfy the trait bound you might as well introduce your own type that contains just the extracted parameters as fit. Afaik all the work to build up the url in the code snippet above could be done by a extractor.

The biggest reason why the core library doesn't only use such a reduced/'normalized' type for the request representation is that your handlers (mostly the OwnerSolicitor) may need access to other information attached only to the original object. For instance, the security considerations recommend verifying that any request that passes (phishable i.e. than pk-signed) credentials is verified to be TLS-encrypted (and revoke them if that fails). If you want to be prudent in your implementation, you'll need to check the underlying socket / connection object but that is of course only attached at the request.

Looking forward to your idea of unifying this a bit better 👍

[urkle]

@HeroicKatora thanks for the feedback.

There are a lot of improvements I'm planning out for this crate. Largely around making it easier to extend/use within an OpenID Connect set of flows and using it in full async flows. Right now this is the only server-side Oauth implementation I've found for rust. Everything else is client-side usage only. So I'd rather pour in PRs and updates to make this better vs creating my own.