On Sunday, October 28, 2012 9:56:35 PM UTC, Patrik Sundberg wrote: > > 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. > > Reading the code again I now get it. The redirection I was looking for is there. ::unauthorized-uri is the uri I was looking for, misinterpreted the name to mean something else and overlooked it. I see how it fits together now. Will try to get to making the changes that came up in this discussion sometime this week. Thanks
-- 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
