Les Hazlewood wrote:
This implies that the session ID you've acquired came from a previous
interaction with a session, that is:
String sessionID = subject.getSession().getId(); //make this
available for use later somehow
so the sessionId is generated for me so I must keep and maintain my own
mapping of mySessionId->SessionId?
The session ID is generated at the time the session is created in the
SessionDAO implementation's create() method. If you want to create
your own session ID (such as using the full JID), you'll need to
create your own SessionDAO implementation.
To make this easier in the future, I just created this issue:
https://issues.apache.org/jira/browse/SHIRO-122
This will enable custom ID generation capabilities without requiring
you to create or subclass SessionDAO implementations. Until that
feature is implemented, you'll probably need to create a SessionDAO
implementation. You can look at the MemorySessionDAO implementation
to see how it generates the session id for ideas.
In your case, you'll probably need to bind the full JID to the
ThreadContext before creating the session for the first time, and then
when the session needs to be created in your SessionDAO
implementation, access the ThreadContext to get the full JID and use
that then.
For example, if subclassing MemorySessionDAO and creating say an
XmppMemorySessionDAO, you would just override the
generateNewSessionId() method to get the full JID from the
ThreadContext and return it.
Then just plug this SessionDAO implementation into the configuration:
;-) nice hack, I'll use it for now & await the built in capability.
Re Oauth and the existing remoting solution, does anyone have any
thoughts on whether a session per aliased user makes sense? and if so,
how it might be implemented with shiro?
with xmpp at least the 'from' address is somewhat trustable and
difficult to spoof, but with http at least, that certainly isn't the case.
Cheers
