I think different people are asking different questions here. Authenticating via an XHR or similar is very straightforward if you are using a single-step authentication method like the username/password interactive workflow. Just POST to the right URL with username/password data, and carry on based on a successful vs. unsuccessful response.
Authorization within a single-page application is a totally separate question. Now that I've read Ari's question again fresh, I think he's asking "How do I enforce authorization policies when my RPC mechanism (in this case, shoreleave-remote) 'binds' on a single URI, when it looks like all the Friend authorization examples establish policy on a per-URI basis?" (Apologies to Ari if that's *not* what he's asking, but I'll answer that question if anyone's interested…) The answer is that you can use `cemerick.friend/authorize`, `cemerick.friend/authorized?`, `cemerick.friend/throw-unauthorized` in various combinations whereever you need to enforce authorization policy. It does not have to be applied only once, just within the boundary of routing, and it does not even have to be role-based. So, if you expose N functions via shoreleave's RPC mechanism, each of those (or dedicated `defremote`s that delegate to other fns) can contain any arbitrary authorization checks, each potentially changing application behaviour or throwing an authorization failure as your needs demand. That's today, and should suffice for building effectively any application you need. Someday soon however, it will be possible to back into a singular routing+authorization policy table for your entire application, which could include e.g. multiple shoreleave RPC endpoints, each with their own delimited bag of remote-available fns, each potentially guarded by their own authorization criteria. This will hopefully allow for declarative policy specifications, automated reporting of effective policy outside of runtime, allow you to disentangle authorization policy from the rest of your codebase, and altogether make audits less invasive and therefore less costly. I hope the above clarifies more than it confuses. Cheers, - Chas On Apr 1, 2013, at 1:12 PM, albert cortez wrote: > In the same boat here. Trying to make a SPA and now am trying to figure out > the easiest way to have ajax authentification. > > On Tuesday, February 26, 2013 5:24:09 PM UTC+1, Ari wrote: > Hi, > > I'd appreciate suggestions on how I can/should secure my > clojure/clojurescript "single page web" app that relies heavily on > shoreleave-remote. With other frameworks, upon authentication I've created a > "roles" cookie that the clientside uses to determine access rights to views, > while on the serverside I use a "roles" session variable to determine access > rights to GET/POST data. But Shoreleave side-steps the serverside > authentication/authorization (via friend), so I'm not sure how to proceed. > > Thanks. > > -Ari > > > -- > -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
