Redirect prefix
With redirect-prefix, instead of executing baz action's execute() method (by
default it isn't overriden in struts.xml to be something else), it will get
redirected to, in this case to www.google.com. Internally it uses
ServletRedirectResult to do the task.
<s:form action="baz">
<s:textfield label="Enter your name"
name="person.name"/>
<s:submit value="Create person"/>
<s:submit name="redirect:www.google.com"
value="Cancel"/>
</s:form>
struts handles all of those contingencies via actionmapper mapping an
action/namespace to
handle some known URL
http://struts.apache.org/2.0.14/docs/actionmapper.html
(implementing actionmapper doesnt prevent you from giving chris money)
Martin
______________________________________________
Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung/Note de
déni et de confidentialité
This message is confidential. If you should not be the intended receiver, then
we ask politely to report. Each unauthorized forwarding or manufacturing of a
copy is inadmissible. This message serves only for the exchange of information
and has no legal binding effect. Due to the easy manipulation of emails we
cannot take responsibility over the the contents.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Date: Wed, 6 May 2009 21:54:02 -0400
> From: ch...@christopherschultz.net
> To: users@tomcat.apache.org
> Subject: Re: Form-based Container Security with SSL
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Guojun,
>
> On 5/6/2009 3:05 PM, Guojun Zhu wrote:
> > We had a small web application on tomcat 5.5. We use tomcat realm
> > (MD5 digest) with the form-based login. I have a few questions on
> > this.
> >
> > 1. When we use http, does the form-based login page send the username
> > and password plainly or in the digested form?
>
> Your web browser will send the credentials in cleartext. The only
> "digest" being used here is the one used to hash the password before it
> is checked against your database (all on the server side).
>
> If you want the password sent securely, you'll need to either use HTTPS
> or use DIGEST authentication, which uses HTTP Auth instead of forms. I
> prefer HTTPS + form over DIGEST, FWIW.
>
> > 2. We set up the ssl in 8443 port. All links in our application are
> > relative link without the specified scheme. So currently all the
> > links (including login page) go either through normal http or
> > encrypted https. Is there anyway to limit the ssl only for the login
> > page alone and make sure login page always go through ssl? Rest pages
> > are really fairly low-risk stuff and we do not worry about the leak on
> > them.
>
> Are you comfortable with the possibility of session hijacking? If so,
> there is a way to do this that I outlined a few weeks ago. Hmm... I
> can't seem to find it in the archives; I'll give you the short-short
> version. Try something like this:
>
> web.xml:
> <form-login-page>/login.jsp</form-login-page>
> ...
> <security-constraint>
> <web-resource-collection>
> <url-pattern>/login.jsp</url-pattern>
> </web-resource-collection>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> <security-constraint>
>
> login.jsp:
> <%
> Cookie mySessionCookie = ...;
> if(mySessionCookie.isSecure())
> {
> // We don't want a secure session cookie. Kill it,
> // redirect to non-secure page and bounce back.
>
> session.invalidate();
>
> response.sendRedirect(response.encodeRedirectURL(BOUNCE_PAGE));
> }
> %>
>
> Your bounce page should simply create a session and redirect to
> https://yourhost/login.jsp.
>
> You should probably create a filter that watches every URL except your
> login page and drives everything back to HTTP if it finds HTTPS in use.
>
> This may interfere with the container's ability to store and re-play
> requests for protected resources /after/ a successful login. YMMV. If
> you can't get it working using this suggestion, feel free to hire me to
> do it for you ;)
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkoCPzoACgkQ9CaO5/Lv0PAPnwCcC9jIfZ9oc60imAgaw01sfcjJ
> MlEAoIsyPZ9f6dXGo5IInzLXOMxh7vs0
> =9YPw
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
_________________________________________________________________
Hotmail® goes with you.
http://windowslive.com/Tutorial/Hotmail/Mobile?ocid=TXT_TAGLM_WL_HM_Tutorial_Mobile1_052009
