Issues accessing authid from RPC call

#1

Once upon a time, I was able to get at the “authid” from within an RPC call, now it seems I’m limited to the session id only.
Is there a “proper” way to do this, it seems at the moment I have to store the session id in my authenticator (in a common DB) and look it up by session id (in the DB) within the RPC call.

Example;

In JS define a wrapper that calls a topic like so;

call: function(topic,args,success,failure) {
session.call(topic,[args],{},{disclose_me:true}).then(success,failure);
}

``

Then call it with;

var good = function(data) {
console.log(“Ok”);
};
var fail = function(data) {
console.log(“Fail”);
};
call(“app.local.menu”,{},good,fail);

``

I then define the code in Python;

@wamp.register(u’app.load.menu’)
def app_load_menu(self,details=None):
log.msg("> app.load.menu !!!")
log.msg(details.caller)
log.msg(details.procedure)
log.msg(details.progress)
return “payload”

``

This works fine, but all I get in the Python code is “caller” set to the session ID and procedure/progress set to “None”.

log.msg(dir(details))

``

Gives me nothing useful.

So, what’s the “proper” way for app.load.menu to get at “authid” ??

0 Likes

#2

Incidentally, same problem calling from Python;

copts = CallOptions(disclose_me=True)
params = (“hello”,“world”)
self.call(u"app.load.menu",details=params,options=copts)

``

0 Likes

#3

Hi Gareth!

Currently all you get is the sessionID. The idea behind this was to keep the wire traffic to a minimum, and that you’d look up the data for the session once and then cache this in your application.

You are, however, by far not the only one to want more information as part of the caller disclosure. There’s an open issue about this in the WAMP repo - https://github.com/wamp-proto/wamp-proto/issues/57

The current state of discussion about this is that we want to provide sessionID, authrole and authID. Would this cover your use case? A quick comment on the issue to drive things forward would be welcome in any case.

Regards,

Alex

···

Am Donnerstag, 12. November 2015 13:46:37 UTC+1 schrieb Gareth Bult:

Incidentally, same problem calling from Python;

copts = CallOptions(disclose_me=True)
params = (“hello”,“world”)
self.call(u"app.load.menu",details=params,options=copts)

``

0 Likes

#4

Hi Alex,

Thanks for the reply. The issue is that pretty much everything I do needs to know “who” is on the other end of the session. So what I actually need is the session_id for uniqueness, and the authid for identification. Anything else (and there’s no end of other useful information) can be referenced from the authid.

The main issue with the current mechanism is actually converting the session_id into an authid. In my application the dynamic authentication is attached directly to crossbar as a component, whereas everything else runs as a separate module and registers resources, potentially from different machines … so to resolve the authid, I either need to reference a common DB (which is what I currently do, I’m using Mongo) or I need to make a meta-call, which involves a deferred call “inline”, which is not great.

If I had the authid locally, then yes I would need DB lookups to get more data, but the initial lookup would go away, and I wouldn’t need all the cruft I have in the authentication code that writes out login information to a “sessions” file. (and I wouldn’t need to ‘maintain’ the sessions file!)

AND (!) it would also avoid another “gotcha”. At the moment the authenticator relies on subscribing to “wamp.session.on_join” in order to record and cache (in the DB) the session and authid relationship. It is technically possible (I believe) for a user to login and make a request, prior to this notification, which would mean a request from a logged in user that is going to fail because the session .vs. authid has yet to be written to the DB. My current solution to that is to write credentials in the authenticator prior to password validation, but this is a horrible hack and wide open to DOS type issues.

I use the “role” in authorize … not sure I need it further down the line.

(indeed ‘role’ is not that ‘interesting’ to my apps as they use a more involved ‘acl’ approach for more fine-grained access control)

0 Likes

#5

Hi Gareth,

So I take it that your use case would be covered by the proposed extension of the provided information to include the authID. My feeling is that this is what will happen, and I’ve filed an issue for Crossbar.io - https://github.com/crossbario/crossbar/issues/514

regards,

Alex

···

Am Donnerstag, 12. November 2015 15:30:23 UTC+1 schrieb Gareth Bult:

Hi Alex,

Thanks for the reply. The issue is that pretty much everything I do needs to know “who” is on the other end of the session. So what I actually need is the session_id for uniqueness, and the authid for identification. Anything else (and there’s no end of other useful information) can be referenced from the authid.

The main issue with the current mechanism is actually converting the session_id into an authid. In my application the dynamic authentication is attached directly to crossbar as a component, whereas everything else runs as a separate module and registers resources, potentially from different machines … so to resolve the authid, I either need to reference a common DB (which is what I currently do, I’m using Mongo) or I need to make a meta-call, which involves a deferred call “inline”, which is not great.

If I had the authid locally, then yes I would need DB lookups to get more data, but the initial lookup would go away, and I wouldn’t need all the cruft I have in the authentication code that writes out login information to a “sessions” file. (and I wouldn’t need to ‘maintain’ the sessions file!)

AND (!) it would also avoid another “gotcha”. At the moment the authenticator relies on subscribing to “wamp.session.on_join” in order to record and cache (in the DB) the session and authid relationship. It is technically possible (I believe) for a user to login and make a request, prior to this notification, which would mean a request from a logged in user that is going to fail because the session .vs. authid has yet to be written to the DB. My current solution to that is to write credentials in the authenticator prior to password validation, but this is a horrible hack and wide open to DOS type issues.

I use the “role” in authorize … not sure I need it further down the line.

(indeed ‘role’ is not that ‘interesting’ to my apps as they use a more involved ‘acl’ approach for more fine-grained access control)

0 Likes

#6

Hi Alex, yes it would, although as I said, I don’t “need” the role field … :slight_smile:

0 Likes