Not configurable 'redirect_url' for a openidclient

[kpupkov-ppa]

Not configurable 'redirect_url' for a openidclient

[ctron]

The redirect URL is actually constructed from the current URL:

yew-oauth2/src/agent/mod.rs

Lines 378 to 384 in 06a652f

	fn current_url() -> Result<Url, String> {
	let href = window().location().href().map_err(|err| {
	err.as_string()
	.unwrap_or_else(|| "unable to get current location".to_string())
	})?;
	Url::parse(&href).map_err(|err| err.to_string())
	}

But I agree, it might make sense to be able to override this.

There are different ways to deal with this. This could be configured in the oauth2 main configuration, via an optionally provided URL. Or using an optionally provided relative URL maybe. It could also be provided in the LoginOptions struct. What do you think?

[kpupkov-ppa]

@ctron I think more convenient way is to have it at Client config level. You concept of 'Additional', right? That make sense to me put ALL optional additional configurations into this structure with 'predefined' default values. Any other solutions will be less attractive to me.
#[cfg(feature = "openid")] let config = Config { client_id: "XYZ".into(), //Rust OKTA as SPA configuration issuer_url: "https://XYZ-dev.okta.com/oauth2/default".into(), additional: Additional { /* Set the after logout URL to a public URL. Otherwise, the SSO server will redirect back to the current page, which is detected as a new session, and will try to login again, if the page requires this. */ end_session_url: None, after_logout_url: Some("/".into()), post_logout_redirect_name: Some("/".into()), redirect_uri: Some("/login/oauth2/code/okta".into()), ///Other Okta related configs }, };

[ctron]

Yea, that is true. However, we already have the scope on the OAuth2 component properties level (as it is the same for both OAuth2 and OIDC). And now the same for the audience.

However, that doesn't matter as a default can be defined using #[prop_or_default] (or similar attributes).

Maybe it makes sense to define this as Option on both the OAuth2 properties, as well as the LoginOptions, defaulting to the current behavior.

[kpupkov-ppa]

@ctron I don't want to limit you in solution. It makes sense to me for any convenient approach. Just provide in doc several examples how to configure for different use cases.

[ctron]

I won't promise anything, but if you have some time, a PR would definitely help.