Custom Standard Classloader
Hi there, I'd like to specify a custom implementation of 'StandardClassLoader' for Tomcat 6. I've written such an implementation of 'org.apache.catalina.loader.StandardClassLoader' and dropped it onto the classpath (using the Eclipse launch configuration). However, I get an error: java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina It seems that only the lib/* jars are available at this point in time, and not bootstrap.jar. What's the correct way to override the StandardClassLoader? Regards, Paul
Cluster - No faulty members identified
Hello @ll, I have two Tomcat instances (6.0.32 x64 on Windows) on the same server. Both servers make their own clustering with the other physical node independent from each other on the same machine. I get during start of the 2nd Tomcat on the same node the following error: INFO: Receiver Server Socket bound to:/172.30.5.77:4001 04.11.2011 13:32:37 org.apache.catalina.tribes.membership.McastServiceImpl setupSocket INFO: Attempting to bind the multicast socket to /228.0.0.4:45574 04.11.2011 13:32:37 org.apache.catalina.tribes.membership.McastServiceImpl setupSocket INFO: Binding to multicast address, failed. Binding to port only. 04.11.2011 13:32:37 org.apache.catalina.tribes.membership.McastServiceImpl setupSocket INFO: Setting multihome multicast interface to:/178.30.5.77 04.11.2011 13:32:37 org.apache.catalina.ha.tcp.SimpleTcpCluster start SCHWERWIEGEND: Unable to start cluster. org.apache.catalina.tribes.ChannelException: java.net.SocketException: The requested address is not valid in its context; No faulty members identified. What could it be?? Here server.xml from the first tomcat: [.] Engine name=Catalina defaultHost=extranet jvmRoute=worker2 Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster channelSendOptions=8 Manager className=org.apache.catalina.ha.session.DeltaManager expireSessionsOnShutdown=false notifyListenersOnReplication=true/ Channel className=org.apache.catalina.tribes.group.GroupChannel Membership className=org.apache.catalina.tribes.membership.McastService address=228.0.0.4 bind=172.30.5.77 port=45564 frequency=500 dropTime=3000/ Receiver className=org.apache.catalina.tribes.transport.nio.NioReceiver address=auto port=4000 autoBind=100 selectorTimeout=5000 maxThreads=6/ Sender className=org.apache.catalina.tribes.transport.ReplicationTransmitter Transport className=org.apache.catalina.tribes.transport.nio.PooledParallelSender/ /Sender Interceptor className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector / Interceptor className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15In terceptor/ /Channel Valve className=org.apache.catalina.ha.tcp.ReplicationValve filter=/ Valve className=org.apache.catalina.ha.session.JvmRouteBinderValve/ ClusterListener className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/ ClusterListener className=org.apache.catalina.ha.session.ClusterSessionListener/ /Cluster [.] And here the second tomcat: [.] Engine name=Catalina defaultHost=localhost jvmRoute=worker7 Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster channelSendOptions=8 Manager className=org.apache.catalina.ha.session.DeltaManager expireSessionsOnShutdown=false notifyListenersOnReplication=true/ Channel className=org.apache.catalina.tribes.group.GroupChannel Membership className=org.apache.catalina.tribes.membership.McastService address=228.0.0.4 bind=178.30.5.77 port=45574 frequency=500 dropTime=3000/ Receiver className=org.apache.catalina.tribes.transport.nio.NioReceiver address=auto port=4000 autoBind=100 selectorTimeout=5000 maxThreads=6/ Sender className=org.apache.catalina.tribes.transport.ReplicationTransmitter Transport className=org.apache.catalina.tribes.transport.nio.PooledParallelSender/ /Sender Interceptor className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector / Interceptor className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15In terceptor/ /Channel Valve className=org.apache.catalina.ha.tcp.ReplicationValve filter=/ Valve className=org.apache.catalina.ha.session.JvmRouteBinderValve/ ClusterListener className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/ ClusterListener className=org.apache.catalina.ha.session.ClusterSessionListener/
Re: Custom Standard Classloader
On Fri, 4 Nov 2011 11:23:59 +, Paul Wilson wrote: It seems that only the lib/* jars are available at this point in time, and not bootstrap.jar. What's the correct way to override the StandardClassLoader? Just out of curiosity: what do you need it for? -- Mikolaj Rydzewski m...@ceti.pl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
CsrfPreventionFilter - LRU cache
Hi,
I have recently been using
the org.apache.catalina.filters.CsrfPreventionFilter, and I notice that the
documentation for setNonceCacheSize states:
Sets the number of previously issued nonces that will be cached on a
LRU basis to support parallel requests...
However, looking at the implementation of the cache, it appears to be a
FIFO implementation rather than a LRU cache. I'm happy to raise a bug and
supply a patch for whichever is the desired implementation, but need to
determine what the original intention is first - based on the Javadoc it
would suggest that the intention is for the cache to be LRU, could anyone
here confirm that?
In order to act as an LRU cache, the LinkedHashMap(int initialCapacity,
float loadFactor, boolean accessOrder) constructor would need to be used
with accessOrder set to true. Also the add and contains methods would need
to be altered as follows, as LinkedHashMap.containsKey does not act as a
structural modification.
public void add(T key) {
synchronized(cache) {
cache.put(key, key);
}
}
public boolean contains(T key) {
synchronized(cache) {
return cache.get(key) != null;
}
}
Either cache implementation will work for the majority of cases, however I
came across this issue when issuing Ajax requests which repeatedly use the
same nonce string and after 5 requests the value I'm using is ejected from
the (FIFO) cache, changing the cache to LRU fixes this (although could
potentially result in the same token being used for N requests).
Thanks,
Pete
Re: Custom Standard Classloader
I'm hoping to replace it with an aspect weaver. On 4 November 2011 13:13, Mikolaj Rydzewski m...@ceti.pl wrote: On Fri, 4 Nov 2011 11:23:59 +, Paul Wilson wrote: It seems that only the lib/* jars are available at this point in time, and not bootstrap.jar. What's the correct way to override the StandardClassLoader? Just out of curiosity: what do you need it for? -- Mikolaj Rydzewski m...@ceti.pl --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Session expiration - browser -Web application
Hello, Thank you for reading my post. Maybe my question is not purely related to Tomcat but here is my problem: - a user logs into my Webapp; - his session expires; - if he: - presses the F5 key (browser refresh functionality), - goes back to the previous screen using the browser go back one page button... all that was stored in the session is lost and the Webapp behaviour is uncertain. Instead, I wish I go direct him to the Webapp log in page. My Webapp itself behaves properly. My problem occurs only if the user uses browser functionalities or buttons. I don't know how to deal with that issue. Can you help me? Best regards, -- Léa -- View this message in context: http://old.nabble.com/Session-expiration---browser--Web-application-tp32780678p32780678.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session expiration - browser -Web application
On Fri, 2011-11-04 at 07:16 -0700, Léa Massiot wrote: Hello, Thank you for reading my post. Maybe my question is not purely related to Tomcat but here is my problem: - a user logs into my Webapp; - his session expires; - if he: - presses the F5 key (browser refresh functionality), This creates a new session for the user with _none_ of the objects from the old session in it (because it expired). - goes back to the previous screen using the browser go back one page button... all that was stored in the session is lost and the Webapp behaviour is uncertain. Uncertain is a bit vague. This could be a design problem in the app, e.g. if some objects are simply assuming that the session contains certain other objects then you should expect unexpected behaviour. My guess is the behaviours you see are quite certain, just not well understood. Instead, I wish I go direct him to the Webapp log in page. If every page in the web app is supposed to require authentication you need to declare that in web.xml. I'm assuming (perhaps incorrectly) you've already got some declaration in there for form authentication? My Webapp itself behaves properly. My problem occurs only if the user uses browser functionalities or buttons. I don't know how to deal with that issue. Can you help me? Best regards, -- Léa - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session expiration - browser -Web application
@Tim : Thank you for your answer. [Tim wrote:] Uncertain is a bit vague. Yes. Ok. This is my understanding which is uncertain then. What happens is what you wrote: a new session for the user with _none_ of the objects from the old session in it. [Tim wrote:] If every page in the web app is supposed to require authentication you need to declare that in web.xml. Can you tell me how? [Tim wrote:] I'm assuming (perhaps incorrectly) you've already got some declaration in there for form authentication? What are you thinking about? Can you be more precise? I guess I should have examined this issue sooner but things are the way they are, aren't they? Thank you and best regards, -- Léa -- View this message in context: http://old.nabble.com/Session-expiration---browser--Web-application-tp32780678p32781413.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CsrfPreventionFilter - LRU cache
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pete,
On 11/4/11 9:14 AM, Pete Gould wrote:
I have recently been using the
org.apache.catalina.filters.CsrfPreventionFilter, and I notice that
the documentation for setNonceCacheSize states:
Sets the number of previously issued nonces that will be cached on
a LRU basis to support parallel requests...
However, looking at the implementation of the cache, it appears to
be a FIFO implementation rather than a LRU cache. I'm happy to
raise a bug and supply a patch for whichever is the desired
implementation, but need to determine what the original intention
is first - based on the Javadoc it would suggest that the intention
is for the cache to be LRU, could anyone here confirm that?
That's my expectation: LRU means to remove the element that was least
recently used.
In order to act as an LRU cache, the LinkedHashMap(int
initialCapacity, float loadFactor, boolean accessOrder) constructor
would need to be used with accessOrder set to true.
+1
Also the add and contains methods would need to be altered as
follows, as LinkedHashMap.containsKey does not act as a
structural modification.
public void add(T key) { synchronized(cache) { cache.put(key,
key); } }
I'm not sure add() needs to change.
public boolean contains(T key) { synchronized(cache) { return
cache.get(key) != null; } }
+1
Either cache implementation will work for the majority of cases,
however I came across this issue when issuing Ajax requests which
repeatedly use the same nonce string and after 5 requests the value
I'm using is ejected from the (FIFO) cache, changing the cache to
LRU fixes this (although could potentially result in the same token
being used for N requests).
Good catch.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk60GaMACgkQ9CaO5/Lv0PBQXwCgltBfdKYoJLnCLEHWgnm5ryV4
s3kAn0K9L4tz2XnzqoHhFSO07EsmINfk
=ba9N
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Custom Standard Classloader
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul, On 11/4/11 7:23 AM, Paul Wilson wrote: I'd like to specify a custom implementation of 'StandardClassLoader' for Tomcat 6. I've written such an implementation of 'org.apache.catalina.loader.StandardClassLoader' and dropped it onto the classpath (using the Eclipse launch configuration). So, where did it actually go? However, I get an error: java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina It seems that only the lib/* jars are available at this point in time, and not bootstrap.jar. What's the correct way to override the StandardClassLoader? It's hard to say because you are launching Tomcat from within Eclipse. If you were launching it from the command-line, then the classpath used would be predictable. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk60GsQACgkQ9CaO5/Lv0PBWAgCfWUxCU10ZztWkN5JycQX7BRIO otoAnRx29MMARgy1Pw0JenETag9c/RfO =9QQX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CsrfPreventionFilter - LRU cache
Hi,
Okay, great. I guess that I should raise a bug for this then.
The reason that I think that add() needs to change is that it used to be:
cache.put(key, null);
and therefore cache.contains() would return null as it would have to change
to use get(). This is because we can no longer use containsKey(), as that
doesn't count as a structural modification, and therefore the cache would
still be FIFO.
Thanks,
Pete
On Fri, Nov 4, 2011 at 4:58 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pete,
On 11/4/11 9:14 AM, Pete Gould wrote:
I have recently been using the
org.apache.catalina.filters.CsrfPreventionFilter, and I notice that
the documentation for setNonceCacheSize states:
Sets the number of previously issued nonces that will be cached on
a LRU basis to support parallel requests...
However, looking at the implementation of the cache, it appears to
be a FIFO implementation rather than a LRU cache. I'm happy to
raise a bug and supply a patch for whichever is the desired
implementation, but need to determine what the original intention
is first - based on the Javadoc it would suggest that the intention
is for the cache to be LRU, could anyone here confirm that?
That's my expectation: LRU means to remove the element that was least
recently used.
In order to act as an LRU cache, the LinkedHashMap(int
initialCapacity, float loadFactor, boolean accessOrder) constructor
would need to be used with accessOrder set to true.
+1
Also the add and contains methods would need to be altered as
follows, as LinkedHashMap.containsKey does not act as a
structural modification.
public void add(T key) { synchronized(cache) { cache.put(key,
key); } }
I'm not sure add() needs to change.
public boolean contains(T key) { synchronized(cache) { return
cache.get(key) != null; } }
+1
Either cache implementation will work for the majority of cases,
however I came across this issue when issuing Ajax requests which
repeatedly use the same nonce string and after 5 requests the value
I'm using is ejected from the (FIFO) cache, changing the cache to
LRU fixes this (although could potentially result in the same token
being used for N requests).
Good catch.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk60GaMACgkQ9CaO5/Lv0PBQXwCgltBfdKYoJLnCLEHWgnm5ryV4
s3kAn0K9L4tz2XnzqoHhFSO07EsmINfk
=ba9N
-END PGP SIGNATURE-
Re: Session expiration - browser -Web application
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Léa, On 11/4/11 12:04 PM, Léa Massiot wrote: @Tim : Thank you for your answer. [Tim wrote:] Uncertain is a bit vague. Yes. Ok. This is my understanding which is uncertain then. What happens is what you wrote: a new session for the user with _none_ of the objects from the old session in it. The new session created is completely empty. It has nothing to do with the user going back in the history, etc. If you have a lot of data in the request parameters that can keep the state of the workflow sane, then that's a different story. I always try to have enough information in the page (form) so that resuming a workflow after a session timeout is a possibility. This is something you will have to code into your own webapp: it's not something Tomcat can provide for you. [Tim wrote:] If every page in the web app is supposed to require authentication you need to declare that in web.xml. Can you tell me how? Read-up on the servlet spec, specifically the authentication and authorization sections. Look for security-constraint and auth-constraint sections in web.xml. [Tim wrote:] I'm assuming (perhaps incorrectly) you've already got some declaration in there for form authentication? What are you thinking about? Can you be more precise? If users are logging-into your webapp, presumably they are providing a username and password (or other credentials): where do you have that configured? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk60G7QACgkQ9CaO5/Lv0PDIlACgoqsUbBg77GjOYVIbSfkAMbQW I7AAoIXZVd5nMgT4v8fUeXnQTqcpJLmA =IxaF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CsrfPreventionFilter - LRU cache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pete, On 11/4/11 1:06 PM, Pete Gould wrote: Okay, great. I guess that I should raise a bug for this then. The reason that I think that add() needs to change is that it used to be: cache.put(key, null); and therefore cache.contains() would return null as it would have to change to use get(). Oh, of course. Thanks for pointing that out. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk60J08ACgkQ9CaO5/Lv0PDXSgCgmtaOLeeJ8IlpribL7yLOf2Qz 3XcAoLIER5jONC5azPXj8LOh5MqvXXo2 =HlyO -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session expiration - browser -Web application
@Christopher :
Thank you for your answer.
Christopher wrote:
The new session created is completely empty. It has nothing to do with the
user going back in the history, etc.
No, you are right.
What I meant is that I was/am managing session expiration inside the Webapp
(for instance if the user clicks a button which is inside the Webapp and if
the session has expired, I redirect him to the log in page).
Christopher wrote:
I always try to have enough information in the page (form) so that
resuming a workflow after a session timeout is a possibility.
I'm sorry but I do not understand what you are explaining me here...
A SOLUTION... I THINK.
I have found a solution, here it is:
for all the JSPs which require a user to be identified (*), I add the
following code:
%
ASessionAttribute aSessionAttribute = null;
HttpSession httpSession = null;
httpSession = request.getSession();
aSessionAttribute = (ASessionAttribute)
httpSession.getAttribute(aSessionAttribute);
if(aSessionAttribute == null)
{
response.sendRedirect(the-log-in-page.jsp);
}
%
Then if a user presses the F5 key and if the session has expired, he is
properly redirected to the log in page.
Best regards,
--
Léa
(*) That is to say, in my example, the aSessionAttribute object musn't be
null.
--
View this message in context:
http://old.nabble.com/Session-expiration---browser--Web-application-tp32780678p32782585.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session expiration - browser -Web application
On Fri, 2011-11-04 at 13:07 -0400, Christopher Schultz wrote: On 11/4/11 12:04 PM, Léa Massiot wrote: SNIP I would basically echo what Chris said. [Tim wrote:] I'm assuming (perhaps incorrectly) you've already got some declaration in there for form authentication? What are you thinking about? Can you be more precise? Form authentication is part of the servlet spec. The spec is quite precise and fairly accessible reading. As Chris said, read the sections on authentication and authorization. Trust me, you'll be glad you read it. The servlet 2.5 spec is here: http://download.oracle.com/otn-pub/jcp/servlet-2.5-mrel2-eval-oth-JSpec/servlet-2_5-mrel2-spec.pdf If users are logging-into your webapp, presumably they are providing a username and password (or other credentials): where do you have that configured? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk60G7QACgkQ9CaO5/Lv0PDIlACgoqsUbBg77GjOYVIbSfkAMbQW I7AAoIXZVd5nMgT4v8fUeXnQTqcpJLmA =IxaF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CsrfPreventionFilter - LRU cache
On 04/11/2011 13:14, Pete Gould wrote: Hi, I have recently been using the org.apache.catalina.filters.CsrfPreventionFilter, and I notice that the documentation for setNonceCacheSize states: Sets the number of previously issued nonces that will be cached on a LRU basis to support parallel requests... However, looking at the implementation of the cache, it appears to be a FIFO implementation rather than a LRU cache. I'm happy to raise a bug and supply a patch for whichever is the desired implementation, but need to determine what the original intention is first - based on the Javadoc it would suggest that the intention is for the cache to be LRU, could anyone here confirm that? I wrote the initial implementation of the CsrfPreventionFilter and I honestly can't remember whether I actually intended to implement FIFO or LRU. It isn't beyond the realm of possibility that I started with one and changed my mind. That said, looking at the svn history for that file there aren't any obvious suggestions of a change of mind. Either cache implementation will work for the majority of cases, however I came across this issue when issuing Ajax requests which repeatedly use the same nonce string and after 5 requests the value I'm using is ejected from the (FIFO) cache, changing the cache to LRU fixes this (although could potentially result in the same token being used for N requests). I think the thing to do here is to work out what the 'best' solution is and fix the docs/code accordingly. I think LRU is the way to go in which case the current code needs fixing. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session expiration - browser -Web application
Léa,
Life needn't be this difficult. :-) You're reinventing wheels here
instead of understanding how the wheels you already have work. Again,
read the spec. Pretty please. So many questions will be answered.
On Fri, 2011-11-04 at 11:55 -0700, Léa Massiot wrote:
@Christopher :
Thank you for your answer.
Christopher wrote:
The new session created is completely empty. It has nothing to do with the
user going back in the history, etc.
No, you are right.
What I meant is that I was/am managing session expiration inside the Webapp
(for instance if the user clicks a button which is inside the Webapp and if
the session has expired, I redirect him to the log in page).
Christopher wrote:
I always try to have enough information in the page (form) so that
resuming a workflow after a session timeout is a possibility.
I'm sorry but I do not understand what you are explaining me here...
A SOLUTION... I THINK.
I have found a solution, here it is:
for all the JSPs which require a user to be identified (*), I add the
following code:
Better solution is to check whether the user principle is set. The spec
will explain this.
%
ASessionAttribute aSessionAttribute = null;
HttpSession httpSession = null;
httpSession = request.getSession();
aSessionAttribute = (ASessionAttribute)
httpSession.getAttribute(aSessionAttribute);
if(aSessionAttribute == null)
{
response.sendRedirect(the-log-in-page.jsp);
}
%
Then if a user presses the F5 key and if the session has expired, he is
properly redirected to the log in page.
Best regards,
--
Léa
(*) That is to say, in my example, the aSessionAttribute object musn't be
null.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CsrfPreventionFilter - LRU cache
On Fri, Nov 4, 2011 at 20:23, Mark Thomas ma...@apache.org wrote: [...] I think the thing to do here is to work out what the 'best' solution is and fix the docs/code accordingly. I think LRU is the way to go in which case the current code needs fixing. I see more arguments for the LRU case: when a CSRF attack appears for whatever app is out there, for whatever defintion of appears, it is more likely that the same attack pattern will appear even on unaffected sites. -- Francis Galiegue ONE2TEAM Ingénieur système Mob : +33 (0) 683 877 875 Tel : +33 (0) 178 945 552 f...@one2team.com 40 avenue Raymond Poincaré 75116 Paris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Custom Standard Classloader
On 4 Nov 2011, at 11:24, Paul Wilson paulalexwil...@gmail.com wrote: Hi there, I'd like to specify a custom implementation of 'StandardClassLoader' for Tomcat 6. Why? I've written such an implementation of 'org.apache.catalina.loader.StandardClassLoader' and dropped it onto the classpath What does the above mean, exactly? Sounds like that's what broke it. p (using the Eclipse launch configuration). However, I get an error: java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina It seems that only the lib/* jars are available at this point in time, and not bootstrap.jar. What's the correct way to override the StandardClassLoader? Regards, Paul - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session expiration - browser -Web application
On 4 Nov 2011, at 19:24, Tim Watts t...@cliftonfarm.org wrote:
Léa,
Life needn't be this difficult. :-) You're reinventing wheels here
instead of understanding how the wheels you already have work. Again,
read the spec. Pretty please. So many questions will be answered.
+1
JSP != PHP
The Servlet Container (Tomcat) provides a great deal of functionality for you.
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html
p
On Fri, 2011-11-04 at 11:55 -0700, Léa Massiot wrote:
@Christopher :
Thank you for your answer.
Christopher wrote:
The new session created is completely empty. It has nothing to do with the
user going back in the history, etc.
No, you are right.
What I meant is that I was/am managing session expiration inside the Webapp
(for instance if the user clicks a button which is inside the Webapp and if
the session has expired, I redirect him to the log in page).
Christopher wrote:
I always try to have enough information in the page (form) so that
resuming a workflow after a session timeout is a possibility.
I'm sorry but I do not understand what you are explaining me here...
A SOLUTION... I THINK.
I have found a solution, here it is:
for all the JSPs which require a user to be identified (*), I add the
following code:
Better solution is to check whether the user principle is set. The spec
will explain this.
%
ASessionAttribute aSessionAttribute = null;
HttpSession httpSession = null;
httpSession = request.getSession();
aSessionAttribute = (ASessionAttribute)
httpSession.getAttribute(aSessionAttribute);
if(aSessionAttribute == null)
{
response.sendRedirect(the-log-in-page.jsp);
}
%
Then if a user presses the F5 key and if the session has expired, he is
properly redirected to the log in page.
Best regards,
--
Léa
(*) That is to say, in my example, the aSessionAttribute object musn't be
null.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Vulnerability Remediation
It has been identified to me by our security group that my Apache Tomcat 6.0.33 has the following vulnerability CVE-2011-3190. There is a link on the Apache Tomcat 6.0 Security page to http://svn.apache.org/viewvc?view=revisionrevision=1162959 as a patch. The link list three files: /tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java /tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java /tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml There is no trunk or java/org/apache/coyote directory in my installation. Do I add those directories to apply the patch. I am completely new at all of this so all help and direction is appreciated and necessary. Thanks Brendan P Keenan Mainframe Automation CSC Home Office - Columbia, CT USA GOS | Global Enterprise Service Mgmt | 1.860.416.0251 | bkee...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session expiration - browser -Web application
Héhé. No comment. Have a good week-end and cheers, -- Léa -- View this message in context: http://old.nabble.com/Session-expiration---browser--Web-application-tp32780678p32783180.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Vulnerability Remediation
Brendan, The link is a list of the files that were modified to fix the vulnerability. These files can be used to patch the source code for Tomcat. After patching the source code, you would then need to recompile it and update your Tomcat installation with the recompiled binaries. In my opinion, it's easier to apply one of the mitigations now and upgrade to Tomcat 6.0.34 when it is officially released. * Configure both Tomcat and the reverse proxy to use a shared secret. (It is request.secret attribute in AJP Connector, worker.workername.secret directive for mod_jk. The mod_proxy_ajp module currently does not support shared secrets). * Use the org.apache.jk.server.JkCoyoteHandler (BIO) AJP connector implementation. (It is automatically selected if you do not have Tomcat-Native library installed. It can be also selected explicitly: Connector protocol=org.apache.jk.server.JkCoyoteHandler). Dan On Fri, 2011-11-04 at 13:20 -0700, Brendan P Keenan wrote: It has been identified to me by our security group that my Apache Tomcat 6.0.33 has the following vulnerability CVE-2011-3190. There is a link on the Apache Tomcat 6.0 Security page to http://svn.apache.org/viewvc?view=revisionrevision=1162959 as a patch. The link list three files: /tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java /tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java /tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml There is no trunk or java/org/apache/coyote directory in my installation. Do I add those directories to apply the patch. I am completely new at all of this so all help and direction is appreciated and necessary. Thanks Brendan P Keenan Mainframe Automation CSC Home Office - Columbia, CT USA GOS | Global Enterprise Service Mgmt | 1.860.416.0251 | bkee...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Vulnerability Remediation
2011/11/5 Brendan P Keenan bkee...@csc.com: It has been identified to me by our security group that my Apache Tomcat 6.0.33 has the following vulnerability CVE-2011-3190. There is a link on the Apache Tomcat 6.0 Security page to http://svn.apache.org/viewvc?view=revisionrevision=1162959 as a patch. (...) Do I add those directories to apply the patch. Have you read the first section at the top of that Tomcat 6 security page? http://tomcat.apache.org/security-6.html#Apache_Tomcat_6.x_vulnerabilities Regarding those three files that you mentioned: That is ViewVC program that displays Subversion repository that contains the source code. That page shows what files were changed in revision #1162959 and what the differences were. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
