New releases: Crossbar.io, AutobahnPython and AutobahnJS

[Tobias Oberstein]

Hi all,

we're excited to release new versions of

- Crossbar.io 0.10.2
- AutobahnPython 0.10.1
- AutobahnJS 0.9.6

with major updates and new features! See below.

If you have feedback, issues or opinions, please don't hesitate: we'd
love to hear about!

Cheers,
/Tobias


NEW Features
============

1. Pattern-based Subscriptions

Using this, you can subscribe to a pattern of URIs and you will then
receive events matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Subscriptions/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternsubs


2. Pattern-based Registrations

Using this, you can register a procedure on a pattern of URIs and your
procedure will then be called for calls matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternregs


3. Shared Registrations

With this, multiple components (or instances of a component) can
register a procedure under the same URI specifying a invocation policy.

When a call comes in, the call will be dispatched to one of the sessions
that registered a matching procedure, and the dispatching will be based
on the invocation policy.

Invocation policies include: single, first, last, roundrobin and random.
These allow you to scale-out your application components or configure
hot-standby and fail-over strategies.

Please see the introduction here

http://crossbar.io/docs/Shared-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/sharedregs


4. WAMP Meta Prodedures and Events

Crossbar.io now implements a whole bunch of WAMP meta procedures and topics.

Please see here for introductions

http://crossbar.io/docs/Session-Metaevents-and-Procedures/
http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/
http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/

and here for the complete example

https://github.com/crossbario/crossbarexamples/tree/master/metaapi

===

[Gareth Bult]

Hi,

Having upgraded fro V9 I find that my application no longer works .. "RegisterOptions" it seems no longer supports "discloseCallerTransport" or "discloseCaller" ..

Any chance you could point me at the replacement functionality ?

[Gareth Bult]

Ok, after much reading and tearing of hair I've answered my own question. Rather than keying off authid

(which is what I was doing) I've re-coded to store the authid against the sessionid in the router's authentication

override, then I'm using a db lookup / session cache to resolve the session id back to the authid.

I can see 'why' this was changed .. massive impact on pre-existing code tho' ... one further point I couldn't

quite see, is there an easy way to make call's default to {disclose_me:true} or am I stuck with including it

in each call ?

[Tobias Oberstein]

Hi Gareth,

Am 09.03.2015 um 19:59 schrieb Gareth Bult:
> Ok, after much reading and tearing of hair I've answered my own
> question. Rather than keying off authid

Sorry recent changes have caused you issues - FWIW, the old scheme had 2
flaws:

- each and every call carries all the lengthy details of the caller
maybe even caller transport details
- it made disclosure a decision of the receiver, not the sender (or
router) who should decide about this

In calls/events, if the sender is disclosed, this is done by including
the session ID and only that.

A component interested in caller/publisher details including transport
level information can use the meta API of Crossbar.io

http://crossbar.io/docs/Session-Metaevents-and-Procedures/
http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/
http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/

> (which is what I was doing) I've re-coded to store the authid against
> the sessionid in the router's authentication
> override, then I'm using a db lookup / session cache to resolve the
> session id back to the authid.
>
> I can see 'why' this was changed .. massive impact on pre-existing code
> tho' ... one further point I couldn't
> quite see, is there an easy way to make call's default to
> {disclose_me:true} or am I stuck with including it
> in each call ?

Yeah, that gets old quickly. Alex has just implemented a global option
in AutobahnJS which allows to set disclosure related flags:

https://github.com/tavendo/AutobahnJS/blob/master/package/test/test_rpc_caller_disclose_me.js#L154

Will be in the upcoming AutobahnJS release!

Cheers,
/Tobias

> <http://crossbar.io/docs/Session-Metaevents-and-Procedures/>
> http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/
> <http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/>
> http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/

> <http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/>
>
> and here for the complete example
>
> https://github.com/crossbario/crossbarexamples/tree/master/metaapi

> <https://github.com/crossbario/crossbarexamples/tree/master/metaapi>
>
>
> ===
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Crossbar" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crossbario+...@googlegroups.com
> <mailto:crossbario+...@googlegroups.com>.
> To post to this group, send email to cross...@googlegroups.com
> <mailto:cross...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/crossbario/2e35d266-1989-49a1-a99e-74290358c604%40googlegroups.com
> <https://groups.google.com/d/msgid/crossbario/2e35d266-1989-49a1-a99e-74290358c604%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Alexander Gödde]

Hi Ralph!

As far as I'm aware the only problem with backward compatibility is that the "disclose_caller" option no longer exists for registrations. For the reasons Tobias gives above, this is now under the control of the caller (which can set "disclose_me" on the call). 

Regards,

Alex

Am Sonntag, 15. März 2015 02:02:15 UTC+1 schrieb ralph stone:

what do we need to know about backward compatibility?

[Dante Lorenso]

We find this to be a *horrible* breakage also.

Upon connecting to Crossbar, we will authenticate front-end users with a username and password.  That means we send authid to crossbar as the 'username' of the connecting user.  Inside authenticate, we look up this username and convert it to account_id (return authid = account_id).  We want crossbar to hence forth store and pass the 'account_id' value to all RPC calls.  The account_id is what we need to see for all front-end users with every RPC call that is made.  Instead, now, crossbar is sending only some session id.  We are now forced to look up the session_id to account_id mapping for every call.  

Crossbar already *did* the session_id-to-account_id map lookup on authentication, so why are we being forced to store this mapping in another layer of the system and have to watch wamp.session.on_leave and on_join events to maintain this mapping?  The mapping should be kept inside crossbar and the backend unique account_id should be passed to every backend RPC call automatically, IMHO.

I think Gareth and I have a common usage scenario here.  We want to avoid making developers build more infrastructure than they should have to.

The proposal should be as follows:

- crossbar configuration (config.json) can define that all rpc calls will disclose the caller

- crossbar stores authid for connected sessions (session id mapped to authid)

- authid can be changed to a true back-end unique identifier during authentication (authentication authid IN = username, authentication authid OUT = account_id)

- authid is passed to all RPC calls when disclosure is turned on

With these changes, Crossbar manages the session to account_id lookup table and all backend calls will receive authid disclosure without concern about whether front-end callers remembered to turn on the feature.

-- Dante

[Tobias Oberstein]

Hi Dante,

> crossbar configuration (config.json) can define that all rpc calls will disclose the caller

Agreed, should be possible:  https://github.com/crossbario/crossbar/issues/283

> crossbar stores authid for connected sessions (session id mapped to authid)

This is how it works already. Crossbar.io stores all auth (and transport) level info internally.

> authid can be changed to a true back-end unique identifier during authentication (authentication authid IN = username, authentication authid OUT = account_id)

Already implemented. Please see http://crossbar.io/docs/WAMP-CRA-Authentication/ => Dynamic Auth. => authid: The authentication ID which will be assigned to the client

> authid is passed to all RPC calls when disclosure is turned on

This is where I disagree. The authid is just one info of potential interest. Another developer asked for transport level info (like Cookies from WebSocket handshake).

It doesn't make sense to forward this bulky info on _each and every_ call forwarded.

Instead, you can retrieve it when needed by calling "wamp.session.get" ... you might cache it yourself, or you might just call "wamp.session.get" each time you need it.

Cheers,
/Tobias

[D. Dante Lorenso]

On 3/30/15 9:18 AM, Tobias Oberstein wrote:
> > authid is passed to all RPC calls when disclosure is turned on
>
> This is where I disagree. The authid is just one info of potential
> interest. Another developer asked for transport level info (like Cookies
> from WebSocket handshake).
>
> It doesn't make sense to forward this bulky info on _each and every_
> call forwarded.
>
> Instead, you can retrieve it when needed by calling "|wamp.session.get"
> ...| you might cache it yourself, or you might just call
> "wamp.session.get" each time you need it.

Right now, you are sending a 'caller' detail which is the session_id of
the WAMP connection. What good is this data to me? ... I want the
unique Id of my caller instead. I see the unique id of my connected
client as another RPC parameter. For example, myfunc(a, b, c)

com.example.myfunc ( [ a, b, c, ] )

And Ideally, account_id ("authid") would be in this list of parameters also:

com.example.myfunc ( [ a, b, c, authid ] )

We can't trust the data to come from the client, but we can trust it to
come from Crossbar since Crossbar stores the data after authentication.
So, let's have crossbar pass that info in the details:

com.example.myfunc ( [ a, b, c ], {}, { authid: ... } )

But what you are telling me is that there is much information that would
be in details, so you want to remove it all and instead send a reference
ID that can be used to look up the data later using wamp.session.get!

com.example.myfunc ( [a, b, c], {}, { caller: ... } )

But, now I have to write this code at the top of all of my RPC calls:

account_id = call_wamp_session_get_to_find_authid(callerid);

So, there's a round-trip sub-request to look up the data that you didn't
want to send in the first place! How is that *more* efficient? I
understand that I can cache that lookup in my back-end caller, but what
will that cache look like?

caller "session_id" ---> authid

Does that look familiar? It should, because you *already* have that map
inside Crossbar itself! Why are we duplicating effort here?

What I'm complaining about is that WAMP clients are being forced to
write a layer of code we didn't have to write before. This is a task
that can easily be (and is already being) handled by Crossbar itself.

How about Crossbar adds a configuration value into config.json that
allows us to choose which "details" info are forcefully passed to all
back-end clients? Perhaps an array of names?

"realms" : [ {
...
"roles" : [ {
"id" : "backend",
"name" : "backend",
"permissions" : [ {
"uri" : "*",
"publish" : true,
"subscribe" : true,
"call" : true,
"register" : true
} ],
"force-details" : [ "authid", ... ]
},

By doing this, Crossbar only needs to send a small piece of data (authid
is an integer for me), and can save a lot of work having to look up and
cache this information. Crossbar already has the map, why force another
round-trip call to wamp.session.get when we *know* that call needs to
happen every time anyhow.

With an implementation like "force-details", you also solve the problem
that requires all callers to request 'disclose_me' : true on every call
(isn't that also a waste of payload?). Now, backend role can request
the 'authid' id for each and every RPC request. Clients don't have to
add the disclose me request, and backend WAMP clients don't have to
maintain a caller to account id cache or lookup function.

-- Dante