--- 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
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).
--- 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
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
--- 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
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
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,
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
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
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.
--- 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
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
--- 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
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
-
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
--- 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
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
--- 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
://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]
--- 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
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
--- 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
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.
-
23 matches
Mail list logo
