Tomcat 4 Successfully Authentication Logout
Hello Everybody,
I've a problem logging out from tomcat
form-realm-based authentication. I've been googling
but cant' find anything.
I just want to logout the signed user. That's it.
I'm using JSF with NB visual web pack. I added a
hiperlink which action event has the following code:
currentSession=(HttpSession)FacesContext.getCurrentInstance().getExternalContext().getSession(false);
currentSession.invalidate();
Everything seem to be working fine, even the
SessionBean.destroy() method is called anyway the
Session is still active. I notice this because I
redirect to another page after that and this page is
correctly displayed (the login screen should appear
instead).
I think this is something about order-preprocesing
issues cause the logout link is placed inside a jsp
fragment...
Therefore, I tried sending to a normal JSP which has
the only following code:
%
HttpSession currentSession;
HttpServletResponse resp;
currentSession = (HttpSession)
FacesContext.getCurrentInstance().getExternalContext().getSession(false);
resp = (HttpServletResponse)
FacesContext.getCurrentInstance().getExternalContext().getResponse();
currentSession.invalidate();
try {
response.sendRedirect(Menu.jsp);
} catch (IOException e) {
e.printStackTrace();
}
%
(of course I added the necessary imports...)
But it isn't working either.
Does somebody knows how to correctly logout from
tomcat authentication when using JSF?
thanks in advance.
Comparte video en la ventana de tus mensajes (y también tus fotos de
Flickr).
Usa el nuevo Yahoo! Messenger versión Beta.
http://mx.beta.messenger.yahoo.com/
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 4 Successfully Authentication Logout
Really!??? :|
Is this really NOT possible?!
:S
--- Propes, Barry L [EMAIL PROTECTED]
escribió:
I didn't think (or know) that it was possible. From
previous posts I'd seen I got the idea it was not.
I could be wrong on that, though.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 04, 2007 2:06 PM
To: users@tomcat.apache.org
Subject: Tomcat 4 Successfully Authentication Logout
Hello Everybody,
I've a problem logging out from tomcat
form-realm-based authentication. I've been googling
but cant' find anything.
I just want to logout the signed user. That's it.
I'm using JSF with NB visual web pack. I added a
hiperlink which action event has the following code:
currentSession=(HttpSession)FacesContext.getCurrentInstance().getExternalContext().getSession(false);
currentSession.invalidate();
Everything seem to be working fine, even the
SessionBean.destroy() method is called anyway
the
Session is still active. I notice this because I
redirect to another page after that and this page is
correctly displayed (the login screen should appear
instead).
I think this is something about order-preprocesing
issues cause the logout link is placed inside a jsp
fragment...
Therefore, I tried sending to a normal JSP which has
the only following code:
%
HttpSession currentSession;
HttpServletResponse resp;
currentSession = (HttpSession)
FacesContext.getCurrentInstance().getExternalContext().getSession(false);
resp = (HttpServletResponse)
FacesContext.getCurrentInstance().getExternalContext().getResponse();
currentSession.invalidate();
try {
response.sendRedirect(Menu.jsp);
} catch (IOException e) {
e.printStackTrace();
}
%
(of course I added the necessary imports...)
But it isn't working either.
Does somebody knows how to correctly logout from
tomcat authentication when using JSF?
thanks in advance.
Comparte video en la ventana de tus mensajes
(y también tus fotos de Flickr).
Usa el nuevo Yahoo! Messenger versión Beta.
http://mx.beta.messenger.yahoo.com/
-
To start a new topic, e-mail:
users@tomcat.apache.org
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To start a new topic, e-mail:
users@tomcat.apache.org
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
¡Capacidad ilimitada de almacenamiento en tu correo!
No te preocupes más por el espacio de tu cuenta con Correo Yahoo!:
http://correo.yahoo.com.mx/
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: workers.properties confusion
I think that really depends on the path you use inside your httpd.conf. That's the place where you specify which workers.properties to use. Cheers. --- [EMAIL PROTECTED] escribió: Cool, it is starting to make a bit more sense. Does that mean that setting settings in apache:/etc/httpd/conf/workers.properties will override any workers.properties set in tomcat servers? -Original Message- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: 24 August 2007 15:10 To: Tomcat Users List Subject: Re: workers.properties confusion [EMAIL PROTECTED] wrote: However I am a bit confused between the /etc/httpd/conf/workers.properties for apache and /usr/share/tomcat/conf/workers.properties You only need one workers.properties file: it configures mod_jk for connections to the various Tomcat instances you want to use. Another potential issue is that we are using apache prefork. From what I have googled so far it looks like apache mpm would be better for us. We typically have one apache box sitting in front of 12 tomcats. Prefork works just fine with mod_jk. IIRC, mpm does /not/ work well with mod_jk (or maybe you just have to be careful?). One less thing to worry about then for now. Only reason I thought it might be an issue was because some web pages suggest mpm scales better, and works better on multi cpu systems. Regards __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ¡Sé un mejor fotógrafo! Perfecciona tu técnica y encuentra las mejores fotos. http://mx.yahoo.com/promos/mejorfotografo.html - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat Restarting
Hi everybody, I would like to know what really happen when tomcat is restarted. This is because I need to know the risks of restarting during production time. I mean, if, for example, a servlet is running and at that moment I restart, does tomcat will wait until the jvm finishes and give the generated response or it will just kill every running/pending jvm process? In fact, is there any risk about missing financial transactions? Thank you ;-) ¡Sé un mejor fotógrafo! Perfecciona tu técnica y encuentra las mejores fotos. http://mx.yahoo.com/promos/mejorfotografo.html - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Http Header Cache-Control
Hi again.
I'm still working on this issue. I installed a filter
to all my servlets and now it's working very good. No
problem with that.
This server is running apache and is connected to
tomcat through mod_jk. Since the tomcat applications
are doing OK with the no-cache header, now I'm
configuring apache to add that header to my php
applications.
While I was testing, I discovered that the headers
configured inside apache's httpd.conf were also been
applied to the tomcat apps...
Therefore, now I know that this issue could be
completely solved by just configuring apache.
Gerardo.
--- Nathan Hook [EMAIL PROTECTED] escribió:
There have been at least 3 different highly
intelligent people so far that
have urged you to implement this behavior with a
Filter. After this email
there are going to be 4 (but still only 3 highly
intelligent) people that
urge you to use a Filter for what you're trying to
accomplish.
There are many reasons for using a Filter.
1.) It is APPLICATION behavior that requires your
pages not to be cached.
Not server behavior. Meaning, that if you take your
application and install
it on a different server it will not behave
correctly.
2.) META Tags for controlling cache behavior DO NOT
WORK. The reason that
they don't work is that the servers between your
application and your
browser only look at the header values of a request
for caching. They
(being the intermediary servers) do not inspect the
actual message itself to
read the META Tags. Finally the browser itself
almost always looks at the
header cache values instead of the META Tags.
Whew...
3.) Using a Filter you can program different logic
for different caching
strategies for different media types. For example,
the JSP itself might not
ever want to be cached, but images on the other
hand...we would only want
them requested once and then be cached. Just and
example.
So, to finish up this email...
Use a filter, it just works.
public class CacheControlFilter implements Filter
{
public void init(FilterConfig config) {}
public void destroy() {}
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain filterChain) throws IOException,
ServletException
{
httpResponse.addHeader(Cache-Control,
no-chache, no-store,
must-revalidate, max-age=0, proxy-revalidate,
no-transform, pre-check=0,
post-check=0, private);
filterChain.doFilter(request, response);
}
}
Original Message Follows
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org,
[EMAIL PROTECTED]
Subject: Re: Http Header Cache-Control
Date: Fri, 27 Jul 2007 09:17:54 -0500 (CDT)
Hi,
I'm still studying this problem. While checking the
HTML SPEC
(http://www.w3.org/TR/html4/struct/global.html#h-7.4.4),
I find the following:
---
META and HTTP headers
The http-equiv attribute can be used in place of the
name attribute and has a special significance when
documents are retrieved via the Hypertext Transfer
Protocol (HTTP). HTTP servers may use the property
name specified by the http-equiv attribute to create
an [RFC822]-style header in the HTTP response.
Please
see the HTTP specification ([RFC2616]) for details
on
valid HTTP headers.
The following sample META declaration:
META http-equiv=Expires content=Tue, 20 Aug 1996
14:25:27 GMT
will result in the HTTP header:
Expires: Tue, 20 Aug 1996 14:25:27 GMT
--
Therefore, I'm confused. What's the exact meaning
of:
HTTP servers may use the property name specified by
the http-equiv attribute to create an [RFC822]-style
header in the HTTP response.
Does this means that Tomcat is ignoring this may
part of the specification?
I actually tried to add that meta tags in my
document
but still not getting that in the hppt header.
Thanks.
--- [EMAIL PROTECTED] escribió:
I've got a great link for solving this problem.
Take
a
look at it. Hope that helps somebody.
http://www.onjava.com/pub/a/onjava/2004/03/03/filters.html
--- Christopher Schultz
[EMAIL PROTECTED]
escribió:
To whom it may concern,
[EMAIL PROTECTED] wrote:
Something is wrong with that mod_jk version,
by
the way. The most
recent release of mod_jk is 1.2.23.
Well, the installation file that I found in
the
server is named:
mod_jk-3.3-ap20.so, that's why I assumed that
version.
Strange. You must have some odd packaged
version
of
apache + mod_jk that
has its own (confusing) version number.
This [filter] method looks really cool, any
way,
does somebody knows
another solution. I read about configuring
apache
http.conf and/or
installing the headers module.
Re: Http Header Cache-Control
Apache is not overwritting my tomcat headers. Apache is only appending more headers. I added something like this: Directory /my/httpd/docs/folder/ Header append TODOS_LOS_ARCHIVOS todos los archivos Files *.php Header append Cache-Control no-store, no-cache, must-revalidate Header append SOLO_PHP todos los php /Files /Directory And now, the pages generated by the servlets of my webapp have ALSO the TODOS_LOS_ARCHIVOS header. Moreover, they are in a completely different path. I'm using: apache 1.3.23 tomcat 4.0 how can i know my mod_jk version? Hope to make this clear. ;-) --- Gregor Schneider [EMAIL PROTECTED] escribió: I think you misread your test-results. We performed the same tests here, and the result was, that, if you pass requests via mod_jk to Tomcat as a worker, Apache HTTPD did definately not create / touch any headers but uses the ones returned from the worker (Tomcat) via mod_jk. Versions: Tomcat 5.5 Apache 2.2 mod_jk 1.2.19 all running on Debian 4.0 (Sarge) However, we didn't specify the JK-directives in httpd.conf but we have own config-files for each of our domains which are included in httpd.conf Maybe Rainer (one of the maintainers of mod_jk) is able to shed some light upon our heads... Rainer? Gregor -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ¡Sé un mejor asador! Aprende todo sobre asados. http://mx.yahoo.com/promos/mejorasador.html - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Http Header Cache-Control
Hi, I'm still studying this problem. While checking the HTML SPEC (http://www.w3.org/TR/html4/struct/global.html#h-7.4.4), I find the following: --- META and HTTP headers The http-equiv attribute can be used in place of the name attribute and has a special significance when documents are retrieved via the Hypertext Transfer Protocol (HTTP). HTTP servers may use the property name specified by the http-equiv attribute to create an [RFC822]-style header in the HTTP response. Please see the HTTP specification ([RFC2616]) for details on valid HTTP headers. The following sample META declaration: META http-equiv=Expires content=Tue, 20 Aug 1996 14:25:27 GMT will result in the HTTP header: Expires: Tue, 20 Aug 1996 14:25:27 GMT -- Therefore, I'm confused. What's the exact meaning of: HTTP servers may use the property name specified by the http-equiv attribute to create an [RFC822]-style header in the HTTP response. Does this means that Tomcat is ignoring this may part of the specification? I actually tried to add that meta tags in my document but still not getting that in the hppt header. Thanks. --- [EMAIL PROTECTED] escribió: I've got a great link for solving this problem. Take a look at it. Hope that helps somebody. http://www.onjava.com/pub/a/onjava/2004/03/03/filters.html --- Christopher Schultz [EMAIL PROTECTED] escribió: To whom it may concern, [EMAIL PROTECTED] wrote: Something is wrong with that mod_jk version, by the way. The most recent release of mod_jk is 1.2.23. Well, the installation file that I found in the server is named: mod_jk-3.3-ap20.so, that's why I assumed that version. Strange. You must have some odd packaged version of apache + mod_jk that has its own (confusing) version number. This [filter] method looks really cool, any way, does somebody knows another solution. I read about configuring apache http.conf and/or installing the headers module. I'm sure you can do something like this using Apache httpd only, I'm just not sure how to do it. Is that filter installation the only way in which this could be achieved with tomcat?? There are other ways, but this is the most convenient. Tomcat itself does not support anything like this (that I know of), so you basically have to solve this at an application level. Hope that helps, -chris ¡Sé un mejor fotógrafo! Perfecciona tu técnica y encuentra las mejores fotos. http://mx.yahoo.com/promos/mejorfotografo.html - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ¡Sé un mejor besador! Comparte todo lo que sabes sobre besos. http://mx.yahoo.com/promos/mejorbesador.html - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Http Header Cache-Control
Hello, I've apache 1.3.36 + tomcat 4 + mod_jk 3.3 I'm very new to web servers. I have a problem with the cache configuration of a tomcat web application. Using a http headers inspector, I can see that no cache control is been sent. I'd like to send CacheControl: no-cache in the header of every page of my app. First of all, is this something that I should configure in apache, in tomcat or in mod_jk??? Then, How can I do it? Thanks ;) Llama gratis a cualquier PC del mundo. Con una excelente calidad de sonido. http://mx.messenger.yahoo.com/ - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Http Header Cache-Control
Thanks Christopher, To whom it may concern, [EMAIL PROTECTED] wrote: I've apache 1.3.36 + tomcat 4 + mod_jk 3.3 Something is wrong with that mod_jk version, by the way. The most recent release of mod_jk is 1.2.23. Well, the installation file that I found in the server is named: mod_jk-3.3-ap20.so, that's why I assumed that version. I'm very new to web servers. I have a problem with the cache configuration of a tomcat web application. Using a http headers inspector, I can see that no cache control is been sent. Cache-control headers are usually not sent unless they are necessary. Are you sure they are necessary for your environment? I'd like to send CacheControl: no-cache in the header of every page of my app. First of all, is this something that I should configure in apache, in tomcat or in mod_jk??? I'm sure there are other ways to do this, but in Tomcat, you can do it easily by writing a simple Filter and installing it in your application. Writing a filter is as simple as writing a class that implements javax.servlet.Filter (3 methods) and then installing it by adding this to your WEB-INF/web.xml file: filter filter-nameencodingFilter/filter-name description A filter to ensure that the request has a valid character encoding. This fixes problems when the request is being sent in (say) UTF-8 but the user agent doesn't specify the encoding. /description filter-classorg.childhealthcare.diagnosis.servlet.EncodingFilter/filter-class /filter This stuff goes right at the top of the web.xml file, just inside the web-app element. Note that filters are applied in the order they appear in web.xml, so you might want to familiarize yourself with any existing filters before you install this one. The method you'll want to look for when implementing your filter is HttpServletResponse.addHeader(). You will probably want to add your header /before/ you hand-off processing to the next filter in the chain. Please please /please/ read the documentation for Filter.doFilter before you get started. You can find this documentation here (http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/Filter.html) as well as other places, I'm sure. Hope that helps, -chris This method looks really cool, any way, does somebody knows another solution. I read about configuring apache http.conf and/or installing the headers module. However, I don't know if modifying apache configuration will solve the problem, maybe it's something that should be modified in mod_jk or tomcat. Does somebody knows this??? Is that filter installation the only way in which this could be achieved with tomcat?? Thank You. =) Llama gratis a cualquier PC del mundo. Con una excelente calidad de sonido. http://mx.messenger.yahoo.com/ - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
