You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by pavlinсм <pa...@anyoption.com> on 2016/01/07 09:10:31 UTC
Web app with CMS
Hello,
I am doing a POC of Ignite as a web session replication cache. I have
typical j2ee web application with container managed security, running inside
Tomcat 7. Ignite is set-up following the instructions in the docs and works
fine (really informative in debug mode). The problem is when performing
log-in - the security manager will replace the current session id with a new
one ! Ignite threats the new sessionID as a new session and the application
is loosing reference to the original session.
When I turn off session fixation the problem is gone but I don't like to
lose this security feature.
Any ideas/comments are welcome !
Cheers,
Pavlin
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Web-app-with-CMS-tp2414.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Web app with CMS
Posted by Denis Magda <dm...@gridgain.com>.
Hi,
Thanks, now I see the problem.
Presently Ignite's web session filter doesn't support session ID renewal on
its side. The filter, as you properly noted, just creates a new session from
scratch every time it sees a new session ID.
In any case I think that it's feasible to support session ID renewal at
filter's layer as well. I've created the following task in Apache Ignite
JIRA proposing a possible solution
https://issues.apache.org/jira/browse/IGNITE-2344
Feel free to add you thoughts and details.
Regards,
Denis
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Web-app-with-CMS-tp2414p2451.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Web app with CMS
Posted by pavlinсм <pa...@anyoption.com>.
Denis Magda wrote
> What do you use as a session key then when the session is stored in an
> Ignite cache for further usage?
The session is stored automatically by
org.apache.ignite.cache.websession.WebSessionFilter
Denis Magda wrote
> What is a condition when a user is redirected to the login page rather
> then keep using its old session?
Part of the site is visible for everybody, part of the site is visible for
authenticated users. When the user authenticates HttpServletRequest.login is
changing the session ID ( only the identifier of the session) ->
WebSessionFilter decides this is a new session and creates new entry in the
cache. Note that there is no link between old session ID and new session ID.
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Web-app-with-CMS-tp2414p2427.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Web app with CMS
Posted by Denis Magda <dm...@gridgain.com>.
Pavlin,
What do you use as a session key then when the session is stored in an
Ignite cache for further usage?
What is a condition when a user is redirected to the login page rather then
keep using its old session?
--
Denis
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Web-app-with-CMS-tp2414p2425.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Web app with CMS
Posted by pavlinсм <pa...@anyoption.com>.
Hi Denis,
Unfortunately there is no way to know the newly generated session ID because
it is internally generated by the container and so it is impossible to
replace the old SID in ignite. Changing the session ID after user is
successfully login to the system is valid and very common use case, I guess
using container managed security with ignite will be impossible ...
Cheers,
Pavlin
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Web-app-with-CMS-tp2414p2421.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Web app with CMS
Posted by Denis Magda <dm...@gridgain.com>.
Hi Pavlin,
In my understanding you should configure the security manager in a way
that it will first check with Ignite cache if a session already exists
and replace it only if it doesn't.
If it's impossible by some reason and both the security manager and the
application knows that only the session's ID is changed but its content
is left the same the you can do something like this
Session ses = sessionCache.get(oldSessionId);
sessionCache.put(newSessionId, ses);
P.S.
Just in case sharing the link to [1] with you if you haven't visited
that page before.
[1] https://apacheignite.readme.io/docs/web-session-clustering
--
Denis
On 1/7/2016 11:10 AM, pavlinсм wrote:
> Hello,
>
> I am doing a POC of Ignite as a web session replication cache. I have
> typical j2ee web application with container managed security, running inside
> Tomcat 7. Ignite is set-up following the instructions in the docs and works
> fine (really informative in debug mode). The problem is when performing
> log-in - the security manager will replace the current session id with a new
> one ! Ignite threats the new sessionID as a new session and the application
> is loosing reference to the original session.
> When I turn off session fixation the problem is gone but I don't like to
> lose this security feature.
>
> Any ideas/comments are welcome !
>
> Cheers,
> Pavlin
>
>
>
> --
> View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Web-app-with-CMS-tp2414.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.