Re: resume after login feature
--- Jae K [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
--- Dale Newfield [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
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 [EMAIL PROTECTED] wrote: --- Dale Newfield [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
--- Jae K [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
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=actionNameLogin/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 [EMAIL PROTECTED] wrote:
--- meeboo [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
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.
AAAHhh. 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 [EMAIL PROTECTED] 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=actionNameLogin/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 [EMAIL PROTECTED] wrote:
--- meeboo [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
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 [EMAIL PROTECTED] 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.
AAAHhh. 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 [EMAIL PROTECTED] 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=actionNameLogin/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 [EMAIL PROTECTED] wrote:
--- meeboo [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
--- Jae K [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
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 [EMAIL PROTECTED] wrote:
--- Jae K [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
--- Jae K [EMAIL PROTECTED] 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=rolesrole1, 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
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
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
--- meeboo [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
--- meeboo [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
--- meeboo [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
Gotcha Dave... now all I need is clean URL:s before I can actually consider using this damned framework :) Dave Newton-4 wrote: --- meeboo [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
--- meeboo [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resume after login feature
There is no reason why I cannot, I just wanted to attempt a struts-only approach because then the security realm/namespace is declared along with the rest of my actions. With container managed security I may easily forget to synchronize the web.xml and struts files. Not a big problem though. - Jae On 4/2/07, Christopher Schultz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jae, Jae K wrote: Chris, Thanks for your input. SecurityFilter was on my list as well, and I think it's what I will go for. I'm surprised that noone else is familiar with this particular problem though. Note that securityfilter and the AAA built into Tomcat both support this feature of sending the user to the originally-requested resource (including POST data) after a login. Is there a reason why you cannot use container-managed authentication and authorization? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEYQA9CaO5/Lv0PARAj0ZAJ9k0jGJvCMCYAQ+L+s5Pn+V6BHzawCfXEji G/RzmkTlGi5cM0UhulM99Ws= =GtPw -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
