@@ -50,32 +50,35 @@ use yew::Callback;
50
50
/// to a single page. This can be enabled set setting a specific URL as `redirect_url`.
51
51
///
52
52
/// Once the user comes back from the login flow, which might actually be without any user interaction if the session
53
- /// was still valid, the user might find himself on the redirect page. Therefore, it is advisable to forward/redirect
54
- /// the user back to the original page, after the issuer redirected back to the `redirect_url`. While this crate does
55
- /// provides some assistance, the actual implementation on how to redirect is left to the user of this crate.
56
- /// If, while starting the login process, the currently active URL differs from the `redirect_url`, the agent will store
57
- /// the "current" URL and pass it to the provided "post login redirect callback" once the login process has completed.
53
+ /// was still valid, users might find themselves on the redirect page. Therefore, it is advisable to forward/redirect
54
+ /// back to the original page, the one where the user left off.
55
+ ///
56
+ /// While this crate does provide some assistance, the actual implementation on how to redirect is left to the user
57
+ /// of this crate. If, while starting the login process, the currently active URL differs from the `redirect_url`,
58
+ /// the agent will store the "current" URL and pass it to the provided "post login redirect callback" once the
59
+ /// login process has completed.
58
60
///
59
61
/// It could be argued, that the crate should just perform the redirect automatically, if no call back was provided.
60
62
/// However, there can be different ways to redirect, and there is no common one. One might think just setting a new
61
63
/// location in the browser should work, but that would actually cause a page reload, and would then start the login
62
- /// process again (since the tokens are only held in memory for security reasons).
64
+ /// process again, since the tokens are only held in memory for security reasons. Also using the browser's History API
65
+ /// won't work, as it does not notify listeners when pushing a new state.
63
66
///
64
67
/// Therefore, it is necessary to set a "post login redirect callback", which will be triggered to handle the redirect,
65
- /// in order to allow the user of the crate to implement the needed logic.
66
- /// Having the `yew-nested-router` feature enabled, it is possible to just call [`LoginOptions::with_nested_router_redirect`]
67
- /// and let the router take care of this.
68
+ /// in order to allow the user of the crate to implement the needed logic. Having the `yew-nested-router`
69
+ /// feature enabled, it is possible to just call [`LoginOptions::with_nested_router_redirect`] and let the
70
+ /// router take care of this.
68
71
///
69
- /// **NOTE:** As a summary, setting only the `redirect_url` will no be sufficient. The "psot login redirect callback" must
70
- /// be implemented or the `yew-nested-router`feature used. Otherwise the user would simply end up on the page defined by
71
- /// `redirect_url`, which in most cases would lead to a 404 page not found error .
72
+ /// **NOTE:** As a summary, setting only the `redirect_url` will not be sufficient. The "post login redirect callback" must
73
+ /// also be implemented or the `yew-nested-router`feature used. Otherwise, the user would simply end up on the page defined by
74
+ /// `redirect_url`, which in most cases is not what one would expect .
72
75
#[ derive( Debug , Clone , Default ) ]
73
76
#[ non_exhaustive]
74
77
pub struct LoginOptions {
75
78
/// Additional query parameters sent to the issuer.
76
79
pub query : HashMap < String , String > ,
77
80
78
- /// Defines the redirect URL.
81
+ /// Defines the redirect URL. See ["Redirect & Post login redirect"](#redirect--post-login-redirect) for more information.
79
82
///
80
83
/// If this field is empty, the current URL is used as a redirect URL.
81
84
pub redirect_url : Option < Url > ,
0 commit comments