crossbar: URI based authentication, possible?

#1

Hello,

We have an use case that a particular RPC (create_account) needs to by-pass the normal account-based authentication, therefore wondering if it is possible to associate authentication for particular URI pattern instead of the whole transport of the crossbar router.

Right now we used a dynamic authorization with a websocket transport, which as far as we can see, only determine the authid -> role relationship for a particular realm, regardless of the URI…

0 Likes

#2

We have an use case that a particular RPC (create_account) needs to
by-pass the normal account-based authentication, therefore wondering if
it is possible to associate authentication for particular URI pattern
instead of the whole transport of the crossbar router.

You can have a client that isn't signed up yet authenticate as role "anonymous" and only allow create_account then.

After the client is signed up, reconnect authentiating properly and under a role "user" which then is allows the rest of your API.

That's a common idiom we use ourselfes.

Right now we used a dynamic authorization with a websocket transport,
which as far as we can see, only determine the authid -> role
relationship for a particular realm, regardless of the URI...

Yep.

Permissions are only tied to a role (on a realm), not a transport, and not specific URIs.

Cheers,
/Tobias

0 Likes

#3

ok, I think we can live with that. Thanks Tobias.

P.S. Will be very helpful to document all these common idioms…

···

On Thursday, January 29, 2015 at 7:55:21 AM UTC+8, Tobias Oberstein wrote:

We have an use case that a particular RPC (create_account) needs to

by-pass the normal account-based authentication, therefore wondering if

it is possible to associate authentication for particular URI pattern

instead of the whole transport of the crossbar router.

You can have a client that isn’t signed up yet authenticate as role
“anonymous” and only allow create_account then.

After the client is signed up, reconnect authentiating properly and
under a role “user” which then is allows the rest of your API.

That’s a common idiom we use ourselfes.

Right now we used a dynamic authorization with a websocket transport,

which as far as we can see, only determine the authid -> role

relationship for a particular realm, regardless of the URI…

Yep.

Permissions are only tied to a role (on a realm), not a transport, and
not specific URIs.

Cheers,

/Tobias

0 Likes

#4

In fact, if you are careful, there is no need to reconnect. You can simply leave and rejoin the realm. This is useful of you want to connect when the page first loads (rather than when the user clicks on something). Unfortunately, the code to do this is a little messy. You need to replace onleave in your session.

0 Likes