Using Thread ID to pass parameters around - is it safe?

[junk1]

Heres the question...
If a servlet sticks a bit of information (eg a username) into a Map in
a static class and keys that info using the thread name then is it safe
to assume that a class that eventually gets called (ie several layers
down from orriginal servlet) wil be able to pick this username off of
the static class by getting its thread name and accessing the static
class? (all classes run in same JVM)

....or might there be situations where thread name gets changed half way
down the static or even the thread name gets reused by another user
while the first thread is still active?


Heres the background...
Our Java applications use an inhouse authorisation mechanism which
basically answers questions like 'Can user view sales data'.

These questions are typically asked in the presentation tier where the
users session (and so authToken) is avaliable. But we would like to ask
the same questions at a more granular level further down the stack - ie
a DAO wants to be able to ask a similar question.

We cant just use another auth mechanism, but to ask the question the
DAO needs access to the users auth token (just a pojo that gets put on
the session) so the solution would seem to be to pass this auth token
down to the DAO, but this would 'polute' the signitures of all other
the tiers inbetween as they should only contain business stuff and not
be concerned with security.

....so ideally I need something like the session context, but which
would be easily avaliable from any tier.


Thanks for any help

David Bevan
http://www.davidbevan.co.uk

 

[Robert Klemme]

Heres the question...
If a servlet sticks a bit of information (eg a username) into a Map in
a static class and keys that info using the thread name then is it safe
to assume that a class that eventually gets called (ie several layers
down from orriginal servlet) wil be able to pick this username off of
the static class by getting its thread name and accessing the static
class? (all classes run in same JVM)

Rather use ThreadLocal
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ThreadLocal.html

...or might there be situations where thread name gets changed half way
down the static or even the thread name gets reused by another user
while the first thread is still active?

Thread names do not change. However, I'm not sure whether they are
required to be unique.

Heres the background...
Our Java applications use an inhouse authorisation mechanism which
basically answers questions like 'Can user view sales data'.

These questions are typically asked in the presentation tier where the
users session (and so authToken) is avaliable. But we would like to ask
the same questions at a more granular level further down the stack - ie
a DAO wants to be able to ask a similar question.

We cant just use another auth mechanism, but to ask the question the
DAO needs access to the users auth token (just a pojo that gets put on
the session) so the solution would seem to be to pass this auth token
down to the DAO, but this would 'polute' the signitures of all other
the tiers inbetween as they should only contain business stuff and not
be concerned with security.

...so ideally I need something like the session context, but which
would be easily avaliable from any tier.

Storing this info thread locally is a kind of hack IMHO because it is
quite intransparent (i.e. you're essentially passing an invisible
parameter). Might still be the best solution in your case, but you
should be aware of this fact.

Kind regards

robert

 

[Daniel Dyer]

Rather use ThreadLocal
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ThreadLocal.html


Thread names do not change. However, I'm not sure whether they are
required to be unique.

They can change:

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#setName(java.lang.String)

Using the ID would be safer since it does not change and is unique:

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#getId()

But the ThreadLocal suggestion is a better solution.

Dan.