On Sunday, October 28, 2012 8:14:41 PM UTC, Chas Emerick wrote: > On Oct 28, 2012, at 2:57 PM, Patrik Sundberg wrote: > > I've looked at this for a bit now. It seems there are some slight > inconsistencies in how the redirect info is used: > > Where the redirect-on-autth? is being set up for the interactive-form > workflow it looks to me to be assumed to be a boolean flag. > > https://github.com/sundbp/friend/blob/master/src/cemerick/friend/workflows.clj#L79 > > At that point it's given as an argument when setting up the workflow > (defaulting to true). > > Then when it's being used in the generic code it's first picked out - > looking like boolean flag still: > https://github.com/sundbp/friend/blob/master/src/cemerick/friend.clj#L145 > > but then all of a sudden assumed to be a string containing the url to > redirect to: > https://github.com/sundbp/friend/blob/master/src/cemerick/friend.clj#L149 > > Given that, for the interactive-form workflow, it can only be set at the > time of creating the workflow, it seems impossible to actually achieve the > flow where friend "remembers" which page under authentication that user > tried to access, then do auth, and finally return user to the originally > requested page in a dynamic fashion. Since given at workflow creation time > it can't dynamically reflect things properly I'd have assumed. I'd have > expected it to not be an argument at workflow creation time, but the > originally requested url being dynamically kept track of at the point > friend realizes it needs to redirect the user to do authentication, then > that url being used on L149 up there when the workflow sets > redirect-on-auth? to true. > > Am I misunderstanding the flow or is there a mixup here? The tests only > tests for boolean state, not as a string url. > > > You're misunderstanding. If ::redirect-on-auth? is any truthy value > (which includes strings), then `redirect-new-auth` will either: > > (a) send a redirect to the ::unauthorized-uri as captured in the session, > which is only ever set if the user previously requested a resource for > which they were not authorized (see > https://github.com/cemerick/friend/blob/master/src/cemerick/friend.clj#L200), > or > > (b) redirect to the value of ::redirect-on-auth? if it is a string, or > > (c) redirect to the :default-landing-url specified in the configuration > provided to `authenticate`. > > You're right that (b) will never be the case for the interactive-form > workflow, fundamentally because `cemerick.friend.workflows/make-auth` > merges the `auth-meta` defaults in last, rather than first. That's a valid > point of enhancement; ticket/patch welcome. :-) > > Note that ::redirect-on-auth? _is_ poorly named: it was originally > expected to only be a boolean, thus the '?'. Its name will need to change > in the future to reflect its actual role. > > Ok - I think that's actually what my understanding was :) It just seemed that in the existing workflows if it is stringy (assume make-auth patched although I didn't quite get that yet) it is a fixed string rather than a dynamic value of the url user tried to access. I.e. I can give "/foo" as redirect-on-auth? when setting up the interactive-form workflow, but that's then a fixed url to redirecct to. To redirect to whatever page the user tried to access I'd have thought we need store it away from the original request before we go into the auth process, to later redirect back to it once successfully authenticated.
Patrik -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
