You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jae K <in...@gmail.com> on 2007/04/02 17:31:53 UTC
resume after login feature
Hello all, this is a struts2 question.
I'm trying to implement a feature where a custom AuthenticationInterceptor
would redirect the useragent to a login page, and then after the user logs
in, he is redirected to the original request page.
First, I have to send the original request path has a parameter to the login
page or as a hidden field. To do this I plan to do one of the following.
1) use Redirect-Action with an OGNL param that looks like ${request.path}.
I'm not familiar with OGNL so I'm not sure this will work
2) create a custom Redirect class that will use the HttpServletRequest and
HttpServletResponse objects to send the original request path in the
redirect URL.
Then as a result of the Login action I will need a way to redirect the user
again, this time to the original request path. Again, I plan to use
Redirect-Action with an OGNL param (maybe like ${request.param['origpath']}),
or a custom Redirect class.
Please let me know the path to take, or whether there is a better way to do
this. Thanks in advance.
- Jae
Re: resume after login feature
Posted by Dale Newfield <Da...@Newfield.org>.
Jae K wrote:
> Dale, the "parse" param is set to true by default so I didn't have to set
> it.
D'oh! You're right--it says so right there in the javadoc! When did
that (change) happen? (Or has it always been that way? Online javadoc
for WebWork 2.2.5 seems to suggest it was always that way. Whoops.)
Hope this suggestion isn't annoying this late in your struggles, but
ACEGI already has this "resume" feature (including post params and even
(I think) including uploads)...
...in general I avoid rolling my own security code when possible
figuring I'm more likely to introduce bugs, and since I'd be the only
one using said code, they're less likely to be found/fixed...
(That said, I do have a LoginListener that allows me to do stuff when
acegi tells me certain security events have happened.)
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by Dave Newton <ne...@yahoo.com>.
--- Jae K <in...@gmail.com> wrote:
> I don't want to turn this into flamebait, but do you
> really think that the links you provided are
> sufficient?
All I can say is that they were for me (the Wiki
links, not the API links).
As I said previously I agree that there could be
improvement (I have added another bit about dynamic
results to the result configuration element page along
with a link to the original FAQ entry and put the
application stack element onto the top-level OGNL
page) but the specific things we were talking about
*were* documented, but you had to read to the bottom
of the page in one case and have perused the FAQs in
another.
d.
____________________________________________________________________________________
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by Jae K <in...@gmail.com>.
There are several factors that are multiplicitave in the final utility of a
software package, such as performance, correctness, etc and one of them is
ease of use / documentation. I love javadocs for development, but the
javadoc API is usually never a proper form of overall documentation.
I don't want to turn this into flamebait, but do you really think that the
links you provided are sufficient?
- Jae
On 4/9/07, Dave Newton <ne...@yahoo.com> wrote:
>
> --- Dale Newfield <Da...@Newfield.org> wrote:
> > [links to API docs]
> > I would disagree that "it's not documented".
>
> I think my links were easier to find ;)
>
> d.
>
>
>
>
>
> ____________________________________________________________________________________
> Never miss an email again!
> Yahoo! Toolbar alerts you the instant new Mail arrives.
> http://tools.search.yahoo.com/toolbar/features/mail/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: resume after login feature
Posted by Dave Newton <ne...@yahoo.com>.
--- Dale Newfield <Da...@Newfield.org> wrote:
> [links to API docs]
> I would disagree that "it's not documented".
I think my links were easier to find ;)
d.
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by Dale Newfield <Da...@Newfield.org>.
Jae K wrote:
> Last but not least, it is not obvious that the OGNL expressions need
> to be enclosed in ${} when used in the struts config file. (Is this
> even true? I don't know since it's not documented! It certainly isn't
> documented so in the OGNL documentation).
http://struts.apache.org/2.0.6/struts2-core/apidocs/org/apache/struts2/dispatcher/StrutsResultSupport.html
documents where such OGNL expressions can be used, and refers to
http://struts.apache.org/2.0.6/struts2-core/apidocs/com/opensymphony/xwork2/util/TextParseUtil.html#translateVariables(java.lang.String,%20com.opensymphony.xwork2.util.ValueStack)
to explain just how these expressions are substituted when found in
parsable strings.
I don't disagree that it could be documented in more places, but I would
disagree that "it's not documented".
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by Dave Newton <ne...@yahoo.com>.
--- Jae K <in...@gmail.com> wrote:
> [...] it doesn't require sessions for guest users
I can't get all worked up about a single string in
session for guests who will only use it if they hit a
page where they need to log in, and if they're logging
in, they're not guests anymore!
> For example, the Struts wiki does not explain what
> the 'request' stack value is (I thought it was the
> session request object, but it is not),
While I agree the OGNL docs need some rework:
http://struts.apache.org/2.x/docs/ognl.html
does say "Along with the value stack, the framework
places other objects in the ActionContext, including
Maps representing the application, session, and
request contexts."
Could be clearer, especially for those that don't know
the framework, but it's sorta there, and it's also in
the FAQ:
http://struts.apache.org/2.x/docs/what-are-the-default-variables-in-the-value-stack.html
http://struts.apache.org/2.x/docs/ognl-basics.html
actually mentions 'parameters' down at the bottom, and
specifically states that 'parameters' is for
request.getParameter, 'request' is for
request.getAttribute, etc.
> Last but not least, it is not obvious that the OGNL
> expressions need to be enclosed in ${} when used in
> the struts config file. (Is this even true? I don't
> know since it's not documented! It certainly isn't
> documented so in the OGNL documentation).
That's a config-file issue, not OGNL, and actually is
addressed in the FAQs, but someone or myself will add
a note to the results configuration page (I think that
makes the most sense?)
http://struts.apache.org/2.x/docs/parameters-in-configuration-results.html
> Anyways, are you a developer for Struts Dave?
Brain's too small :/
A lot of the issues with the documentation isn't so
much that the information isn't there, but that it's
somewhat difficult find at times.
...and sometimes you are forced to read to the bottom
of the page ;)
d.
____________________________________________________________________________________
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by Jae K <in...@gmail.com>.
>
>
If you say so; it sure seemed like yours was a lot of
> work, and frankly I'd rather role and/or login-aware
> actions implemented something specific to that
> functionality, for a couple of reasons.
>
Hello Dave:
in terms of work, yours and mine are about the same complexity. However, I
prefer my solution because it doesn't require sessions for guest users, and
this is a good measure for performance. To each his own. :)
I think S2 handles this trivially, but if something
> else handled it better, then what would it matter?
Now I see that S3 handles it trivially, but how would a beginner to S2/OGNL
know without implementing it for himself? Whether or not somethign else
handles it better is irrelevant. The question was whether S2 is flexible
enough for the tasks that I need done.
Regarding OGNL documentation, bear in mind that OGNL
> is a *completely* separate project. The basics are
> mostly covered on the Wiki, if you need more
> information than that then the OGNL reference
> documentation would be the reasonable place to look.
I'm aware, the wiki makes it pretty clear. On the other hand, the overlap
between Struts and OGNL (i.e. what variables are available in the stack for
OGNL expressions etc) is NOT documented well, and that documentation belongs
squarely in the Struts wikis. For example, the Struts wiki does not explain
what the 'request' stack value is (I thought it was the session request
object, but it is not), and some important stack values are not listed.
(such as 'parameters'). Last but not least, it is not obvious that the OGNL
expressions need to be enclosed in ${} when used in the struts config file.
(Is this even true? I don't know since it's not documented! It certainly
isn't documented so in the OGNL documentation).
This is why I asked about wiki authorship permissions.
Anyways, are you a developer for Struts Dave? You've been very helpful,
thanks.
- Jae
Re: resume after login feature
Posted by Dave Newton <ne...@yahoo.com>.
--- Jae K <in...@gmail.com> wrote:
> The only difference between your implementation and
> mine is that you put the originalUrl in a session
> whereas I store it away in the client. They're both
> the same 'cleanlinest' i think.
If you say so; it sure seemed like yours was a lot of
work, and frankly I'd rather role and/or login-aware
actions implemented something specific to that
functionality, for a couple of reasons.
So when I compare these chunks:
<param name="location">
${#parameters['origurl'] == null ?
'Welcome.do' : #parameters['origurl']}
</param>
<s:form action="Login.do" validate="true">
<s:if test="${param.origurl ne null}">
<s:hidden name="origurl"
value="${param.origurl}"/>
</s:if>
etc. to:
<action name="login" class="resume.LoginAction">
<result name="input">
/WEB-INF/jsp/resume/login.jsp
</result>
<result name="success" type="redirect">
${originalUrl}
</result>
</action>
<action name="page1" class="resume.Page1Action">
<param name="roles">role1, role2</param>
<result>/WEB-INF/jsp/resume/page1.jsp</result>
</action>
... and a ~50-line interceptor I can't help but like
it. If you chain the login action result it's even
easier and more encapsulated, but so far I prefer the
login url appears for login rather than holding on to
the original request URL; I'm still undecided.
> Dale, I was considering ACEGI / SecurityFilter, but
> I still had to make sure that this feature was
> *possible* before deciding to use Struts.
I think S2 handles this trivially, but if something
else handled it better, then what would it matter?
Regarding OGNL documentation, bear in mind that OGNL
is a *completely* separate project. The basics are
mostly covered on the Wiki, if you need more
information than that then the OGNL reference
documentation would be the reasonable place to look.
d.
____________________________________________________________________________________
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by Jae K <in...@gmail.com>.
Thanks Dave for that sanity check. The only difference between your
implementation and mine is that you put the originalUrl in a session whereas
I store it away in the client. They're both the same 'cleanlinest' i think.
Dale, I was considering ACEGI / SecurityFilter, but I still had to make sure
that this feature was *possible* before deciding to use Struts. If the
framework can't handle login-resume easily, then it can't be a good
framework. Fortunately everything works fine.
- Jae
On 4/8/07, Dave Newton <ne...@yahoo.com> wrote:
>
> --- Jae K <in...@gmail.com> wrote:
> > Of course in Login.jsp you need...
> > <s:form action="Login.do" validate="true">
> > <s:if test="${param.origurl ne null}">
> > <s:hidden name="origurl"
> > value="${param.origurl}"/>
> > </s:if>
> > ....
> >
> > And finally, this has the side effect that all
> > links on the login page created with <s:url ...>
> > will also have the origurl parameter. You can
> > override this behavior by setting
> > includeParams="none" (i think), but it's not
> > strictly necessary because the <s:form ...>
> > action does not inherit those parameters.
>
> I *still* believe you are making this weirder than it
> needs to be and that earlier advice given would lead
> to a better solution (or you could use Acegi as
> suggested--I found it very irritating at first,
> though!)
>
> As a proof of concept, I did (more or less) the
> following, just as a sanity check:
>
> - IRolesAware
>
> Actions requiring login implement this (contains
> get/setRoles) and are given a "roles" <param.../> in
> their struts config. Not a perfect solution, but for
> demonstration purposes it's fine.
>
> - RolesInterceptor
>
> If the invoked action impls IRolesAware it checks for
> login, if not logged in it puts the requested URL
> (with query string) into session and returns the login
> page's global result.
>
> - LoginAction
>
> If login succeeds puts the original url from session
> into a property originalUrl and returns a SUCCESS
> result, which is a result for LoginAction that looks
> like:
>
> <result type="redirect">${originalUrl}</result>
>
> ...also set loggedIn indicator and removes
> originalUrl.
>
> So there is nothing special going on; you check for a
> login in the interceptor (and can check for specific
> roles against the roles the action expects, but that's
> not really part of the discussion). Not logged in,
> save URL and go to login. (Optionally if not right
> role, go to wherever you need to based on whatever
> criteria you want.) Logged in and/or have the role,
> process the invocation normally.
>
> It just seems cleaner; what am I missing?
>
> d.
>
>
>
>
>
> ____________________________________________________________________________________
> TV dinner still cooling?
> Check out "Tonight's Picks" on Yahoo! TV.
> http://tv.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: resume after login feature
Posted by Dave Newton <ne...@yahoo.com>.
--- Jae K <in...@gmail.com> wrote:
> Of course in Login.jsp you need...
> <s:form action="Login.do" validate="true">
> <s:if test="${param.origurl ne null}">
> <s:hidden name="origurl"
> value="${param.origurl}"/>
> </s:if>
> ....
>
> And finally, this has the side effect that all
> links on the login page created with <s:url ...>
> will also have the origurl parameter. You can
> override this behavior by setting
> includeParams="none" (i think), but it's not
> strictly necessary because the <s:form ...>
> action does not inherit those parameters.
I *still* believe you are making this weirder than it
needs to be and that earlier advice given would lead
to a better solution (or you could use Acegi as
suggested--I found it very irritating at first,
though!)
As a proof of concept, I did (more or less) the
following, just as a sanity check:
- IRolesAware
Actions requiring login implement this (contains
get/setRoles) and are given a "roles" <param.../> in
their struts config. Not a perfect solution, but for
demonstration purposes it's fine.
- RolesInterceptor
If the invoked action impls IRolesAware it checks for
login, if not logged in it puts the requested URL
(with query string) into session and returns the login
page's global result.
- LoginAction
If login succeeds puts the original url from session
into a property originalUrl and returns a SUCCESS
result, which is a result for LoginAction that looks
like:
<result type="redirect">${originalUrl}</result>
...also set loggedIn indicator and removes
originalUrl.
So there is nothing special going on; you check for a
login in the interceptor (and can check for specific
roles against the roles the action expects, but that's
not really part of the discussion). Not logged in,
save URL and go to login. (Optionally if not right
role, go to wherever you need to based on whatever
criteria you want.) Logged in and/or have the role,
process the invocation normally.
It just seems cleaner; what am I missing?
d.
____________________________________________________________________________________
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by Jae K <in...@gmail.com>.
Here is the correct OGNL expression:
<param name="location">${#parameters['origurl'] == null ? 'Welcome.do' :
#parameters['origurl']}</param>
Of course in Login.jsp you need...
<s:form action="Login.do" validate="true">
<s:if test="${param.origurl ne null}">
<s:hidden name="origurl" value="${param.origurl}"/>
</s:if>
....
And finally, this has the side effect that all links on the login page
created with <s:url ...> will also have the origurl parameter. You can
override this behavior by setting includeParams="none" (i think), but it's
not strictly necessary because the <s:form ...> action does not inherit
those parameters.
- Jae
On 4/8/07, Jae K <in...@gmail.com> wrote:
>
> It turns out that ${ServletRequest.requestURI } is the correct OGNL
> expression. Of course you need to have a "getServletRequest" method in your
> action superclass, which means all of your actions for your application that
> requires a login will have to implement that method or subclass from a class
> that does.
>
> Dale, the "parse" param is set to true by default so I didn't have to set
> it.
>
> The second part requires redirecting to the origurl location after a
> successful login. This the OGNL expression I have so far, but it's not
> working yet. I'll post again once i fix it.
>
> <param name="location">${#ServletRequest.parameter["origurl"] == null ? "
> Welcome.do" : #ServletRequest.parameter["origurl"]}</param>
>
>
> On 4/8/07, Jae K <in...@gmail.com> wrote:
> >
> > Right after posting this I realized that my AuthenticationInterceptor
> > was the first interceptor to be called, and that's why the ServletRequest
> > object wasn't set.
> >
> > AAAHHHHHhh. I've been burned by the config twice already (the first time
> > was when using the struts-default.xml config, ValidationInterceptor is
> > configured not to validate for certain methods), but I'm willing to admit
> > that it's my dumb oversight.
> >
> > Now I need to get the OGNL syntax right.
> >
> > On 4/8/07, Jae K <in...@gmail.com> wrote:
> > >
> > > Sigh... I tried tackling the first half of this problem today. The
> > > first part is getting the original requested URL as a parameter to the
> > > RedirectActionResult.
> > >
> > > </global-results>
> > > <result name="login" type="redirect-action">
> > > <param name="actionName">Login</param>
> > > <param name="namespace">/</param>
> > > <param name="origurl">${ServletRequest.requestURI}</param> <-- not sure about the OGNL here.
> > > </result>
> > > </global-results>
> > >
> > > All of my actions extend MySupport, which implement
> > > ServletRequestAware. I fired my debugger to see whether the request object
> > > would even be set (with the setServletRequest method) in my action before
> > > the redirect-action is executed. NO! I don't think I can access the
> > > ServletRequest object from the redirect-action configuration!
> > >
> > > My only remaining option is to create my own redirect class that taps
> > > into the ServletRequest object via the invocation object. Rigth now S2 is
> > > looking very very unattractive as a web framework, because the OGNL features
> > > are not well documented (esp in relation to struts results), and because the
> > > given Result and Interceptor classes are not suitable for my basic needs
> > > such as resume after redirect.
> > >
> > > - Jae
> > >
> > > On 4/6/07, Dave Newton < newton.dave@yahoo.com> wrote:
> > > >
> > > > --- meeboo <de...@gmail.com> wrote:
> > > > > One last question regarding this. As I beforehand
> > > > > don't know where to redirect the user after the
> > > > login
> > > > > action I will have to implement the
> > > > > ServletResponseAware interface and then use the
> > > > > HttpServletResponse for this. This seems like an
> > > > ugly
> > > > > way to redirect the user, are there other ways
> > > > maybe?
> > > >
> > > > As someone else mentioned if you are using an
> > > > interface to set the original URL (like void
> > > > setOriginalUrl(String) & String getOriginalUrl()) then
> > > > you can map a redirect in your action's config, more
> > > > or less like the following:
> > > >
> > > > <result type="redirect">${originalUrl}</result>
> > > >
> > > > That was a day or two ago; I don't have a reference to
> > > > it handy and I don't recall who the poster was.
> > > >
> > > > d.
> > > >
> > > >
> > > >
> > > >
> > > > ____________________________________________________________________________________
> > > >
> > > > It's here! Your new message!
> > > > Get new email alerts with the free Yahoo! Toolbar.
> > > > http://tools.search.yahoo.com/toolbar/features/mail/
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > > For additional commands, e-mail: user-help@struts.apache.org
> > > >
> > > >
> > >
> >
>
Re: resume after login feature
Posted by Jae K <in...@gmail.com>.
It turns out that ${ServletRequest.requestURI } is the correct OGNL
expression. Of course you need to have a "getServletRequest" method in your
action superclass, which means all of your actions for your application that
requires a login will have to implement that method or subclass from a class
that does.
Dale, the "parse" param is set to true by default so I didn't have to set
it.
The second part requires redirecting to the origurl location after a
successful login. This the OGNL expression I have so far, but it's not
working yet. I'll post again once i fix it.
<param name="location">${#ServletRequest.parameter["origurl"] == null ? "
Welcome.do" : #ServletRequest.parameter["origurl"]}</param>
On 4/8/07, Jae K <in...@gmail.com> wrote:
>
> Right after posting this I realized that my AuthenticationInterceptor was
> the first interceptor to be called, and that's why the ServletRequest object
> wasn't set.
>
> AAAHHHHHhh. I've been burned by the config twice already (the first time
> was when using the struts-default.xml config, ValidationInterceptor is
> configured not to validate for certain methods), but I'm willing to admit
> that it's my dumb oversight.
>
> Now I need to get the OGNL syntax right.
>
> On 4/8/07, Jae K <in...@gmail.com> wrote:
> >
> > Sigh... I tried tackling the first half of this problem today. The first
> > part is getting the original requested URL as a parameter to the
> > RedirectActionResult.
> >
> > </global-results>
> > <result name="login" type="redirect-action">
> > <param name="actionName">Login</param>
> > <param name="namespace">/</param>
> > <param name="origurl">${ServletRequest.requestURI}</param> <-- not sure about the OGNL here.
> > </result>
> > </global-results>
> >
> > All of my actions extend MySupport, which implement ServletRequestAware.
> > I fired my debugger to see whether the request object would even be set
> > (with the setServletRequest method) in my action before the redirect-action
> > is executed. NO! I don't think I can access the ServletRequest object from
> > the redirect-action configuration!
> >
> > My only remaining option is to create my own redirect class that taps
> > into the ServletRequest object via the invocation object. Rigth now S2 is
> > looking very very unattractive as a web framework, because the OGNL features
> > are not well documented (esp in relation to struts results), and because the
> > given Result and Interceptor classes are not suitable for my basic needs
> > such as resume after redirect.
> >
> > - Jae
> >
> > On 4/6/07, Dave Newton < newton.dave@yahoo.com> wrote:
> > >
> > > --- meeboo <de...@gmail.com> wrote:
> > > > One last question regarding this. As I beforehand
> > > > don't know where to redirect the user after the
> > > login
> > > > action I will have to implement the
> > > > ServletResponseAware interface and then use the
> > > > HttpServletResponse for this. This seems like an
> > > ugly
> > > > way to redirect the user, are there other ways
> > > maybe?
> > >
> > > As someone else mentioned if you are using an
> > > interface to set the original URL (like void
> > > setOriginalUrl(String) & String getOriginalUrl()) then
> > > you can map a redirect in your action's config, more
> > > or less like the following:
> > >
> > > <result type="redirect">${originalUrl}</result>
> > >
> > > That was a day or two ago; I don't have a reference to
> > > it handy and I don't recall who the poster was.
> > >
> > > d.
> > >
> > >
> > >
> > >
> > > ____________________________________________________________________________________
> > >
> > > It's here! Your new message!
> > > Get new email alerts with the free Yahoo! Toolbar.
> > > http://tools.search.yahoo.com/toolbar/features/mail/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> >
>
Re: resume after login feature
Posted by Dale Newfield <Da...@Newfield.org>.
Jae K wrote:
> Now I need to get the OGNL syntax right.
One thing that'll help is adding a "parse" param (set to true)
http://struts.apache.org/2.0.6/struts2-core/apidocs/org/apache/struts2/dispatcher/StrutsResultSupport.html
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by Jae K <in...@gmail.com>.
Right after posting this I realized that my AuthenticationInterceptor was
the first interceptor to be called, and that's why the ServletRequest object
wasn't set.
AAAHHHHHhh. I've been burned by the config twice already (the first time was
when using the struts-default.xml config, ValidationInterceptor is
configured not to validate for certain methods), but I'm willing to admit
that it's my dumb oversight.
Now I need to get the OGNL syntax right.
On 4/8/07, Jae K <in...@gmail.com> wrote:
>
> Sigh... I tried tackling the first half of this problem today. The first
> part is getting the original requested URL as a parameter to the
> RedirectActionResult.
>
> </global-results>
> <result name="login" type="redirect-action">
> <param name="actionName">Login</param>
> <param name="namespace">/</param>
> <param name="origurl">${ServletRequest.requestURI}</param> <-- not sure about the OGNL here.
> </result>
> </global-results>
>
> All of my actions extend MySupport, which implement ServletRequestAware. I
> fired my debugger to see whether the request object would even be set (with
> the setServletRequest method) in my action before the redirect-action is
> executed. NO! I don't think I can access the ServletRequest object from the
> redirect-action configuration!
>
> My only remaining option is to create my own redirect class that taps into
> the ServletRequest object via the invocation object. Rigth now S2 is looking
> very very unattractive as a web framework, because the OGNL features are not
> well documented (esp in relation to struts results), and because the given
> Result and Interceptor classes are not suitable for my basic needs such as
> resume after redirect.
>
> - Jae
>
> On 4/6/07, Dave Newton <ne...@yahoo.com> wrote:
> >
> > --- meeboo <de...@gmail.com> wrote:
> > > One last question regarding this. As I beforehand
> > > don't know where to redirect the user after the
> > login
> > > action I will have to implement the
> > > ServletResponseAware interface and then use the
> > > HttpServletResponse for this. This seems like an
> > ugly
> > > way to redirect the user, are there other ways
> > maybe?
> >
> > As someone else mentioned if you are using an
> > interface to set the original URL (like void
> > setOriginalUrl(String) & String getOriginalUrl()) then
> > you can map a redirect in your action's config, more
> > or less like the following:
> >
> > <result type="redirect">${originalUrl}</result>
> >
> > That was a day or two ago; I don't have a reference to
> > it handy and I don't recall who the poster was.
> >
> > d.
> >
> >
> >
> >
> > ____________________________________________________________________________________
> >
> > It's here! Your new message!
> > Get new email alerts with the free Yahoo! Toolbar.
> > http://tools.search.yahoo.com/toolbar/features/mail/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
Re: resume after login feature
Posted by Jae K <in...@gmail.com>.
Sigh... I tried tackling the first half of this problem today. The first
part is getting the original requested URL as a parameter to the
RedirectActionResult.
</global-results>
<result name="login" type="redirect-action">
<param name="actionName">Login</param>
<param name="namespace">/</param>
<param name="origurl">${ServletRequest.requestURI}</param>
<-- not sure about the OGNL here.
</result>
</global-results>
All of my actions extend MySupport, which implement ServletRequestAware. I
fired my debugger to see whether the request object would even be set (with
the setServletRequest method) in my action before the redirect-action is
executed. NO! I don't think I can access the ServletRequest object from the
redirect-action configuration!
My only remaining option is to create my own redirect class that taps into
the ServletRequest object via the invocation object. Rigth now S2 is looking
very very unattractive as a web framework, because the OGNL features are not
well documented (esp in relation to struts results), and because the given
Result and Interceptor classes are not suitable for my basic needs such as
resume after redirect.
- Jae
On 4/6/07, Dave Newton <ne...@yahoo.com> wrote:
>
> --- meeboo <de...@gmail.com> wrote:
> > One last question regarding this. As I beforehand
> > don't know where to redirect the user after the
> login
> > action I will have to implement the
> > ServletResponseAware interface and then use the
> > HttpServletResponse for this. This seems like an
> ugly
> > way to redirect the user, are there other ways
> maybe?
>
> As someone else mentioned if you are using an
> interface to set the original URL (like void
> setOriginalUrl(String) & String getOriginalUrl()) then
> you can map a redirect in your action's config, more
> or less like the following:
>
> <result type="redirect">${originalUrl}</result>
>
> That was a day or two ago; I don't have a reference to
> it handy and I don't recall who the poster was.
>
> d.
>
>
>
>
>
> ____________________________________________________________________________________
> It's here! Your new message!
> Get new email alerts with the free Yahoo! Toolbar.
> http://tools.search.yahoo.com/toolbar/features/mail/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: resume after login feature
Posted by Dave Newton <ne...@yahoo.com>.
--- meeboo <de...@gmail.com> wrote:
> One last question regarding this. As I beforehand
> don't know where to redirect the user after the
login
> action I will have to implement the
> ServletResponseAware interface and then use the
> HttpServletResponse for this. This seems like an
ugly
> way to redirect the user, are there other ways
maybe?
As someone else mentioned if you are using an
interface to set the original URL (like void
setOriginalUrl(String) & String getOriginalUrl()) then
you can map a redirect in your action's config, more
or less like the following:
<result type="redirect">${originalUrl}</result>
That was a day or two ago; I don't have a reference to
it handy and I don't recall who the poster was.
d.
____________________________________________________________________________________
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by meeboo <de...@gmail.com>.
One last question regarding this. As I beforehand don't know where to
redirect the user after the login action I will have to implement the
ServletResponseAware interface and then use the HttpServletResponse for
this. This seems like an ugly way to redirect the user, are there other ways
maybe?
Dave Newton-4 wrote:
>
> --- meeboo <de...@gmail.com> wrote:
>> Yeah Dave, the problem is passing the data. I have
>> my Login.java action class which implements
>> ServletRequestAware but it'll of course only
> retrieve
>> localhost:8080/login.action since that's the request
>> URI. I need to somehow tell it which location the
>> user tried to login from so that it can redirect
>> back to that specific page.
>
> Passing information to an Action is trivial; implement
> a known or new interface and set the data inside the
> interceptor.
>
> You don't care about the *action's* view of
> request-land, you care about the *interceptor's*
> request; that's where the original (request) is, no?
>
> d.
>
>
>
>
> ____________________________________________________________________________________
> Don't pick lemons.
> See all the new 2007 cars at Yahoo! Autos.
> http://autos.yahoo.com/new_cars.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/resume-after-login-feature-tf3506442.html#a9870255
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by Dave Newton <ne...@yahoo.com>.
--- meeboo <de...@gmail.com> wrote:
> Gotcha Dave... now all I need is clean URL:s before
> I can actually consider using this damned framework
Clean URLs?
FYI, the source for
org.apache.struts2.interceptor.ServletConfigInterceptor
shows how to access the request, from which you can
grab the original URL to pass to your login action.
Briefly:
if (action instanceof ServletRequestAware) {
HttpServletRequest request =
(HttpServletRequest)
context.get(HTTP_REQUEST);
((ServletRequestAware)
action).setServletRequest(request);
}
...but obviously you'd want to build up the URL and
use something like (pseudo-config):
<action name="login" type="...">
<result type="redirect">${originalUrl}</result>
</action>
d.
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by meeboo <de...@gmail.com>.
Gotcha Dave... now all I need is clean URL:s before I can actually consider
using this damned framework :)
Dave Newton-4 wrote:
>
> --- meeboo <de...@gmail.com> wrote:
>> Yeah Dave, the problem is passing the data. I have
>> my Login.java action class which implements
>> ServletRequestAware but it'll of course only
> retrieve
>> localhost:8080/login.action since that's the request
>> URI. I need to somehow tell it which location the
>> user tried to login from so that it can redirect
>> back to that specific page.
>
> Passing information to an Action is trivial; implement
> a known or new interface and set the data inside the
> interceptor.
>
> You don't care about the *action's* view of
> request-land, you care about the *interceptor's*
> request; that's where the original (request) is, no?
>
> d.
>
>
>
>
> ____________________________________________________________________________________
> Don't pick lemons.
> See all the new 2007 cars at Yahoo! Autos.
> http://autos.yahoo.com/new_cars.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/resume-after-login-feature-tf3506442.html#a9857985
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by Dave Newton <ne...@yahoo.com>.
--- meeboo <de...@gmail.com> wrote:
> Yeah Dave, the problem is passing the data. I have
> my Login.java action class which implements
> ServletRequestAware but it'll of course only
retrieve
> localhost:8080/login.action since that's the request
> URI. I need to somehow tell it which location the
> user tried to login from so that it can redirect
> back to that specific page.
Passing information to an Action is trivial; implement
a known or new interface and set the data inside the
interceptor.
You don't care about the *action's* view of
request-land, you care about the *interceptor's*
request; that's where the original (request) is, no?
d.
____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by meeboo <de...@gmail.com>.
Yeah Dave, the problem is passing the data. I have my Login.java action class
which implements ServletRequestAware but it'll of course only retrieve
localhost:8080/login.action since that's the request URI. I need to somehow
tell it which location the user tried to login from so that it can redirect
back to that specific page.
Dave Newton-4 wrote:
>
> --- meeboo <de...@gmail.com> wrote:
>> I'm kind of stumped on this problem too, how can I
>> send the original request uri to the login action so
>
>> that it knows what page to redirect to?
>
> Which is the problem; getting the original request, or
> sending data to the action?
>
> Sending data to the action is easy; you can use an
> existing interface (like parameter aware, etc.) to
> pass a key/value, or you can create a new known
> interface (like setOriginalRequest or whatever) and
> use that.
>
> The OP had a few ideas for getting the original
> request, so I assume your question is passing the
> data?
>
> d.
>
>> Jae K wrote:
>>> I'm trying to implement a feature where a custom
>>> AuthenticationInterceptor would redirect the
>>> useragent to a login page, and then after the user
>>> logs in, he is redirected to the original request
>>> page.
>>>
>>> First, I have to send the original request path
>>> has a parameter to the login page or as a hidden
>>> field. To do this I plan to do one of the
> following.
>>> 1) use Redirect-Action with an OGNL param that
>>> looks like ${request.path}. I'm not familiar with
>>> OGNL so I'm not sure this will work
>>> 2) create a custom Redirect class that will use
>>> the HttpServletRequest and HttpServletResponse
>>> objects to send the original request path in the
>>> redirect URL.
>
>
>
>
> ____________________________________________________________________________________
> Get your own web address.
> Have a HUGE year through Yahoo! Small Business.
> http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/resume-after-login-feature-tf3506442.html#a9857239
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by Dave Newton <ne...@yahoo.com>.
--- meeboo <de...@gmail.com> wrote:
> I'm kind of stumped on this problem too, how can I
> send the original request uri to the login action so
> that it knows what page to redirect to?
Which is the problem; getting the original request, or
sending data to the action?
Sending data to the action is easy; you can use an
existing interface (like parameter aware, etc.) to
pass a key/value, or you can create a new known
interface (like setOriginalRequest or whatever) and
use that.
The OP had a few ideas for getting the original
request, so I assume your question is passing the
data?
d.
> Jae K wrote:
>> I'm trying to implement a feature where a custom
>> AuthenticationInterceptor would redirect the
>> useragent to a login page, and then after the user
>> logs in, he is redirected to the original request
>> page.
>>
>> First, I have to send the original request path
>> has a parameter to the login page or as a hidden
>> field. To do this I plan to do one of the
following.
>> 1) use Redirect-Action with an OGNL param that
>> looks like ${request.path}. I'm not familiar with
>> OGNL so I'm not sure this will work
>> 2) create a custom Redirect class that will use
>> the HttpServletRequest and HttpServletResponse
>> objects to send the original request path in the
>> redirect URL.
____________________________________________________________________________________
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: resume after login feature
Posted by meeboo <de...@gmail.com>.
I'm kind of stumped on this problem too, how can I send the original request
uri to the login action so that it knows what page to redirect to?
Jae K wrote:
>
> Hello all, this is a struts2 question.
>
> I'm trying to implement a feature where a custom AuthenticationInterceptor
> would redirect the useragent to a login page, and then after the user logs
> in, he is redirected to the original request page.
>
> First, I have to send the original request path has a parameter to the
> login
> page or as a hidden field. To do this I plan to do one of the following.
> 1) use Redirect-Action with an OGNL param that looks like ${request.path}.
> I'm not familiar with OGNL so I'm not sure this will work
> 2) create a custom Redirect class that will use the HttpServletRequest and
> HttpServletResponse objects to send the original request path in the
> redirect URL.
>
> Then as a result of the Login action I will need a way to redirect the
> user
> again, this time to the original request path. Again, I plan to use
> Redirect-Action with an OGNL param (maybe like
> ${request.param['origpath']}),
> or a custom Redirect class.
>
> Please let me know the path to take, or whether there is a better way to
> do
> this. Thanks in advance.
>
> - Jae
>
>
--
View this message in context: http://www.nabble.com/resume-after-login-feature-tf3506442.html#a9856930
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org