CallDetails not completely populated

[Greg Fausak]

I have registered a callback:

reg = yield self.register(list_data, 'adm.session.list', options = RegisterOptions(details_arg = 'details'))

Then, when I call the 'adm.session.list' topic:

rv = yield self.call('adm.session.list', options = CallOptions(timeout=2000,discloseMe = True))

In my list_data function I am not getting most of the Caller settings:

details.caller 1502781270

details.authid None

details.authrole None

details.authmethod None

details.caller_transport None

I am getting the session id.  The user is authenticated. Version 0.9.3-3.

Happy Thanksgiving!

-g

[Greg Fausak]

More details about the example above.

The details.caller: is possibly a session ID, but, it is not the session id of the session caller.  I have found that if I start many new sessions, the details.caller stays the same until I restart the router.

I dug into this a bit further, it is ultimately related to my ability to 'authorize'.  I looked at the example authorization application in the Autobahn source tree.  It shows a Router being subclassed and overriding the 'authorize' method.  That method implements this:

   @abc.abstractmethod

   def authorize(self, session, uri, action):

      """

      Authorization hook: check if the given ``session`` is authorized to perform

      the given ``action`` on the given ``uri``.

      :param session: Application session on which the action is to be authorized.

      :type session: A provider of :class:`autobahn.wamp.interfaces.ISession`.

      :param uri: The URI on which the session wants to perform the action.

      :type uri: str

      :param action: The action the session wants to perform. One of

         ``IRouter.ACTION_CALL``, ``IRouter.ACTION_REGISTER``,

         ``IRouter.ACTION_PUBLISH`` or ``IRouter.ACTION_SUBSCRIBE``.

      :type action: int

      """

I think this means that the 'session' being passed to the authorize method is the session to check to see if it is authorized to to the operation.  However, I checked here, the session is not changing.  Even though I start up different applications and make a call over and over (many different session) when I print out the 'session' being passed to this routine the session is not changing.

I thought maybe it was the 9.3.3-3 code, so I went back to 9.2, that didn't help.  

The uri and action being passed to myrouter is correct, that is, I am starting a new session, and calling sys.db.query, which is being authorized with self, session, uri, action.  uri is sys.db.query, and action is 1 (call).  The session ID comes through each time, but, it is NOT the session of the caller.  What am I missing ?

-g

[Greg Fausak]

A little time with the debugger shows that the session is not the session to authorize, rather, I believe it is the session that contains the registered call to be authorized.

That leave me with a bit of a problem in the authorize() method.  I know 'what' I am authorizing (the uri and the action.  And the example application handily shows how to check to see if the uri matches the string 'com.test' or whatever.  However, what if I want to authorize for a specific role/user.  Can I know who I am doing this authorization for?  I have specified the relevant RegisterOptions and CallOptions for disclosing the user.  I wouldn't think that would matter here, though.  When doing 'authorization' you need to know who you are authorizing for, and I can't seem to locate that information.   All I can find is 'what' is being authorized.

Any help would be appreciated :-)

-g

[Tobias Oberstein]

Am 27.11.2014 16:14, schrieb Greg Fausak:
> I have registered a callback:
>
> reg = yield self.register(list_data, 'adm.session.list', options =
> RegisterOptions(details_arg = 'details'))
>
> Then, when I call the 'adm.session.list' topic:
>

> rv = yieldself.call('adm.session.list', options =

> CallOptions(timeout=2000,discloseMe = True))
>
> In my list_data function I am not getting most of the Caller settings:
>
> details.caller 1502781270
>
> details.authid None
>
> details.authrole None
>
> details.authmethod None
>
> details.caller_transport None
>
>
> I am getting the session id. The user is authenticated. Version 0.9.3-3.

Did you try Crossbar.io with your custom authentication code? It does
work ..

Cheers,
/Tobias

>
>
> Happy Thanksgiving!
>
> -g
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Autobahn" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to autobahnws+...@googlegroups.com
> <mailto:autobahnws+...@googlegroups.com>.
> To post to this group, send email to autob...@googlegroups.com
> <mailto:autob...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/autobahnws/d7a03299-c5f1-49ec-bce3-978932d06414%40googlegroups.com
> <https://groups.google.com/d/msgid/autobahnws/d7a03299-c5f1-49ec-bce3-978932d06414%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Greg Fausak]

My authorization code works in crossbar, or crossbar's authorization works in crossbar?

-g

> <mailto:autobahnws+unsub...@googlegroups.com>.

[Greg Fausak]

Arrgghh...

I found the bug with my 'discloseMe' issue.  I have a registered method being called from my client.  Then I have a registered method being called from this registered method.  Obviously the second one will report the caller being the intermediate. Mystery solved!

I've been looking at the crossbar dynamic authorization code.  It does confirm my suspicion, that the session being passed to the authorize method is not the client session to be authorized.  Can I get the sessionid, or the authid, of the session to be authorized in Autobahn?  The reference that crossbar.io makes to: 

return self._session.call(self._authorizer, session._session_details, uri, action)

_session_details is a private variable, also, it doesn't exist on Autobahn.  Is the originating sessionid or authid available in the authorize function in Autobahn?

-g

[Tobias Oberstein]

Hi Greg,

good to hear you've found the issue .. or at least solved part of it. I'm on the road, cannot look much around in code on a 4 inch display .. so I cannot assist right now.

In general, expect the routing code in Crossbar.io diverge and surpass the basic router in AutobahnPython more and more. In particular over the coming months as we ramp up dev on advanced WAMP features and router-to-router communication. It might even no longer subclass AB router classes ...

Sent from Mobile (Google Nexus 5)

To unsubscribe from this group and stop receiving emails from it, send an email to autobahnws+...@googlegroups.com.
To post to this group, send email to autob...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/autobahnws/6d5e9f0f-fab4-4262-a779-aee493ea8a17%40googlegroups.com.