URL Rewriting

[Joao Batistella]

Hello!

Why sometimes and I can see the the attribute jsessionid in the URL of my
app and sometimes and I can't?
Anybody know how to control this behaviour?

Thanks,
JP

Re: Help URL Rewriting

[Michael E. Allen]

Christian Bollmeyer wrote:
Am Freitag, 23. Januar 2004 19:59 schrieb Michael E. Allen:

Where would I put that?


Already tried putting it in the <%@ page [..] %> on top of
your JSP pages? :-) As Struts tends to create a session implicitly,
such as for storing the default locale settings etc, doing so 
in the end would show no real effect anyway (provided that
you're not doing direct JSP calls, but wrap them into a 
standard Struts forward action at least, which is definitely 
recommendable).

Considering the URL rewriting issue: just yesterday I
wrote about enforcing Cookies (for certain parts of
the application that won't work otherwise, among
these those invoking external systems written in
other languages inside a session-wide transaction),
so I better refer to that post here. Normally,
supporting URL rewriting is definitely a good
thing, and you shouldn't suppress this fine
mechanism unless you have to. If you have to,
still, you can always say session.invalidate()
and do a normal forward, in a custom Action.
HTH,
-- Chris.


Anyway... I ended up doing a double redirect... the first to get the
cookie set and the second to get the URL without the "?JSESSION=xxx"
stuff appended.
Eric Bariaux wrote:

What about session=false on your jsp page directive? Would this
help? Eric.

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Michael E.
Allen Sent: Thursday, January 22, 2004 10:37 PM
To: [EMAIL PROTECTED]
Subject: Re: Help URL Rewriting
Ted Husted wrote:

The container can't be sure that any given client supports
cookies,
so


it will always use URL rewriting on the first request.
Is there any way to shut that off?  From and Action I am returning
an ActionForward from the execute that maps to an jnlp file.  The
"?jsessionid=090280243" at the end is messing up starting java web
start.  I can tell me users to hit refresh once and it will go
away... but there should be a better way!
I am not using jsp... the page I want to forward to is a jnlp file (java 
web start), so there is no jsp directive in that file.  I am not a jsp 
programmer, so I thought perhaps there was a configuration file somewhere.

In any case, neither setting session=false nor calling 
session.invalidate() will do what I want; because I *do*, in fact, want 
there to be a session.  I just don't want the JSESSIONID appended to the 
url on the first call.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Help URL Rewriting

[Christian Bollmeyer]

Am Freitag, 23. Januar 2004 19:59 schrieb Michael E. Allen:
> Where would I put that?

Already tried putting it in the <%@ page [..] %> on top of
your JSP pages? :-) As Struts tends to create a session implicitly,
such as for storing the default locale settings etc, doing so 
in the end would show no real effect anyway (provided that
you're not doing direct JSP calls, but wrap them into a 
standard Struts forward action at least, which is definitely 
recommendable).

Considering the URL rewriting issue: just yesterday I
wrote about enforcing Cookies (for certain parts of
the application that won't work otherwise, among
these those invoking external systems written in
other languages inside a session-wide transaction),
so I better refer to that post here. Normally,
supporting URL rewriting is definitely a good
thing, and you shouldn't suppress this fine
mechanism unless you have to. If you have to,
still, you can always say session.invalidate()
and do a normal forward, in a custom Action.

HTH,
-- Chris.


> Anyway... I ended up doing a double redirect... the first to get the
> cookie set and the second to get the URL without the "?JSESSION=xxx"
> stuff appended.
>
> Eric Bariaux wrote:
> > What about session=false on your jsp page directive? Would this
> > help? Eric.
> >
> >>-Original Message-
> >>From: news [mailto:[EMAIL PROTECTED] On Behalf Of Michael E.
> >> Allen Sent: Thursday, January 22, 2004 10:37 PM
> >>To: [EMAIL PROTECTED]
> >>Subject: Re: Help URL Rewriting
> >>
> >>Ted Husted wrote:
> >>>The container can't be sure that any given client supports
> >>> cookies,
> >
> > so
> >
> >>>it will always use URL rewriting on the first request.
> >>
> >>Is there any way to shut that off?  From and Action I am returning
> >> an ActionForward from the execute that maps to an jnlp file.  The
> >> "?jsessionid=090280243" at the end is messing up starting java web
> >> start.  I can tell me users to hit refresh once and it will go
> >> away... but there should be a better way!
> >>
> >>Thanks,
> >>Michael
> >>
> >>
> >>
> >>---
> >>-- To unsubscribe, e-mail:
> >> [EMAIL PROTECTED] For additional
> >> commands, e-mail: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Help URL Rewriting

[Michael E. Allen]

Where would I put that?

Anyway... I ended up doing a double redirect... the first to get the 
cookie set and the second to get the URL without the "?JSESSION=xxx" 
stuff appended.

Eric Bariaux wrote:
What about session=false on your jsp page directive? Would this help?
Eric.

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Michael E. Allen
Sent: Thursday, January 22, 2004 10:37 PM
To: [EMAIL PROTECTED]
Subject: Re: Help URL Rewriting
Ted Husted wrote:

The container can't be sure that any given client supports cookies,
so

it will always use URL rewriting on the first request.

Is there any way to shut that off?  From and Action I am returning an
ActionForward from the execute that maps to an jnlp file.  The
"?jsessionid=090280243" at the end is messing up starting java web
start.  I can tell me users to hit refresh once and it will go away...
but there should be a better way!
Thanks,
Michael


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Help URL Rewriting

[Eric Bariaux]

What about session=false on your jsp page directive? Would this help?
Eric.

> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Michael E. Allen
> Sent: Thursday, January 22, 2004 10:37 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Help URL Rewriting
> 
> Ted Husted wrote:
> > The container can't be sure that any given client supports cookies,
so
> > it will always use URL rewriting on the first request.
> >
> 
> Is there any way to shut that off?  From and Action I am returning an
> ActionForward from the execute that maps to an jnlp file.  The
> "?jsessionid=090280243" at the end is messing up starting java web
> start.  I can tell me users to hit refresh once and it will go away...
> but there should be a better way!
> 
> Thanks,
> Michael
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Help URL Rewriting

[Michael E. Allen]

Ted Husted wrote:
The container can't be sure that any given client supports cookies, so 
it will always use URL rewriting on the first request.

Is there any way to shut that off?  From and Action I am returning an 
ActionForward from the execute that maps to an jnlp file.  The 
"?jsessionid=090280243" at the end is messing up starting java web 
start.  I can tell me users to hit refresh once and it will go away... 
but there should be a better way!

Thanks,
Michael


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Help URL Rewriting

[Ted Husted]

The container can't be sure that any given client supports cookies, so 
it will always use URL rewriting on the first request.

-Ted.

michel Van Asten wrote:
Hi,

I have a strut application running with ServletExec 4.1 (patch 20...)
I want to manage my session with cookies... not url rewrinting
need to disable url Rewriting (to complicate to explain why here...)
1) I Enable cookie in my explorer
2) E disable url rewrinting with ServletExec admin
...

But I still have this code in my start page ??

 <
BR>
How can I control that the cookie is generated ???

Regards,

Michel Van Asten

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Help URL Rewriting

[michel Van Asten]

Hi,

I have a strut application running with ServletExec 4.1 (patch 20...)
I want to manage my session with cookies... not url rewrinting
need to disable url Rewriting (to complicate to explain why here...)
1) I Enable cookie in my explorer
2) E disable url rewrinting with ServletExec admin

...

But I still have this code in my start page ??

 <
BR>


How can I control that the cookie is generated ???

Regards,

Michel Van Asten


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Disable URL-rewriting?

[Brice Ruth]

I'm going to handle this by specifically looking at the User-Agent 
header that gets sent ... if I can detect that it is a search engine 
(particularly *our search engine crawler), then I'll disable the 
encodeURL/Url methods ... otherwise, I'll leave things as is.

This takes care of your considerations, I think.

Brice

Christian Bollmeyer wrote:

Am Dienstag, 18. November 2003 20:10 schrieb Kris Schneider:

Oh, I see that I left that approach out, for I dropped it at an
early stage in my design considerations. Of course, you can
kill off session information via a filter that way, but what will
happen if the user has disabled Cookies, and when it's
not Google, but some John Doe user? OK, let's simulate the
results. Request number #1 is made, resulting in session
creation due to something in my code, but the filter intercepts
and removes the session info from the response. So far,
so good. Now the user clicks on a link. As the request
contains no session info, the server handles it as a
new session-related request and creates a new session.
Returning, the filter kills the session again, of course.
And so on. In the meantime, there may be 30+ stale
sessions hanging around, waiting for timeout just 
because the filter suppressed some crucial infor-
mation the server expected on return. Given it's
possible to say session.invalidate() somewhere in
time before committing the response via the filter, I
still would feel like doing something very wrong
somehow, for I would code against the machine
and the specifications, and that's not how it's
meant to be. It may work, even, but still I would
feel just uneasy. Then, the preferable approach
would be to avoid sessions if you don't want them
(just as in RL) instead of killing them afterwards,
If that's not possible, I tend to handle general
things in a general fashion and handle the special
conditions (possible scenario: the GoogleBot
shows up again) in special ways, too. Considering
a customized Google filter: well, the simple cloaking
approach I described is easier to implement and
just closer to my personal taste. YMMV.

Thanks for an interesting idea I may have
dropped too soon back then, but I think,
even when reconsidering it, I would still
stick to a different approach. It's my
private site after all, and I just don't
want to feel bad about it in some way :-)
-- Chris.

NB. One thing I still wonder about is whether
it's really the jsessionid thing Google dislikes
or the *.do ending in general. AFAI can tell,
Google also indexes plain .jsps, but those
run in a session anyway by default. Don't
know. If it's really just the *.do ending, it's eas
to map Struts to *.html (assigning a .htm ending
to truly static pages), use mod_rewrite or
the rewrite filter available in Resin 3.0.
But didn't check all that yet. 

 

NAFAIK, but that's by no means definitive. I *do* know that you can
configure a TC context (or default context) to do the opposite. In
other words, turn off cookies and only use rewriting.
Hm, what if you create a filter to wrap the response with an
HttpServletResponseWrapper that no-ops encodeUrl and encodeURL?
Quoting Brice Ruth <[EMAIL PROTECTED]>:
   

Is there any way to disable URL rewriting (with jsessionid) in
Tomcat or via struts-config.xml or anything? I'm about at my wits
end with this jsessionid thing - now our search engine which
indexes by crawling the site (and doesn't support cookies) can't
index properly because of the jsessionid property ... and frankly,
I'm not really caring at this point if the 3-5% of visitors to our
site can't use sessions (there's practically no functionality that
depends on it anyway - mainly a performance improvement, where it
is being used). I'd like to leave sessions via cookies enabled, but
disable URL rewriting for sessions.
--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Disable URL-rewriting?

[Christian Bollmeyer]

Am Dienstag, 18. November 2003 20:10 schrieb Kris Schneider:

Oh, I see that I left that approach out, for I dropped it at an
early stage in my design considerations. Of course, you can
kill off session information via a filter that way, but what will
happen if the user has disabled Cookies, and when it's
not Google, but some John Doe user? OK, let's simulate the
results. Request number #1 is made, resulting in session
creation due to something in my code, but the filter intercepts
and removes the session info from the response. So far,
so good. Now the user clicks on a link. As the request
contains no session info, the server handles it as a
new session-related request and creates a new session.
Returning, the filter kills the session again, of course.
And so on. In the meantime, there may be 30+ stale
sessions hanging around, waiting for timeout just 
because the filter suppressed some crucial infor-
mation the server expected on return. Given it's
possible to say session.invalidate() somewhere in
time before committing the response via the filter, I
still would feel like doing something very wrong
somehow, for I would code against the machine
and the specifications, and that's not how it's
meant to be. It may work, even, but still I would
feel just uneasy. Then, the preferable approach
would be to avoid sessions if you don't want them
(just as in RL) instead of killing them afterwards,
If that's not possible, I tend to handle general
things in a general fashion and handle the special
conditions (possible scenario: the GoogleBot
shows up again) in special ways, too. Considering
a customized Google filter: well, the simple cloaking
approach I described is easier to implement and
just closer to my personal taste. YMMV.

Thanks for an interesting idea I may have
dropped too soon back then, but I think,
even when reconsidering it, I would still
stick to a different approach. It's my
private site after all, and I just don't
want to feel bad about it in some way :-)

-- Chris.

NB. One thing I still wonder about is whether
it's really the jsessionid thing Google dislikes
or the *.do ending in general. AFAI can tell,
Google also indexes plain .jsps, but those
run in a session anyway by default. Don't
know. If it's really just the *.do ending, it's eas
to map Struts to *.html (assigning a .htm ending
to truly static pages), use mod_rewrite or
the rewrite filter available in Resin 3.0.
But didn't check all that yet. 
 
> NAFAIK, but that's by no means definitive. I *do* know that you can
> configure a TC context (or default context) to do the opposite. In
> other words, turn off cookies and only use rewriting.
>
> Hm, what if you create a filter to wrap the response with an
> HttpServletResponseWrapper that no-ops encodeUrl and encodeURL?
>
> Quoting Brice Ruth <[EMAIL PROTECTED]>:
> > Is there any way to disable URL rewriting (with jsessionid) in
> > Tomcat or via struts-config.xml or anything? I'm about at my wits
> > end with this jsessionid thing - now our search engine which
> > indexes by crawling the site (and doesn't support cookies) can't
> > index properly because of the jsessionid property ... and frankly,
> > I'm not really caring at this point if the 3-5% of visitors to our
> > site can't use sessions (there's practically no functionality that
> > depends on it anyway - mainly a performance improvement, where it
> > is being used). I'd like to leave sessions via cookies enabled, but
> > disable URL rewriting for sessions.
> >
> > --
> > Brice D. Ruth
> > Sr. IT Analyst
> > Fiskars Brands, Inc.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Disable URL-rewriting?

[Brice Ruth]

Got it.

Simple as pie, actually. Created the Wrapper class, no-op'd the 
encodeUrl/encodeURL and put it into the Filter that was already setup to 
handle all incoming requests ... piece of cake :)

Sweet!

Here's the wrapper code:

public class StripSessionIdWrapper extends HttpServletResponseWrapper {
   public StripSessionIdWrapper(HttpServletResponse response)
   {
   super(response);
   }
   public String encodeUrl(String url) { return url; }
   public String encodeURL(String url) { return url; }
}
and here's the couple lines I have in my Filter:

StripSessionIdWrapper wrapper = new 
StripSessionIdWrapper((HttpServletResponse)response);

and then, instead of passing "response" to the chain.doFilter, I pass 
"wrapper"

Nice ... clean, I like it.
Kris Schneider wrote:
First, check out a tutorial on Servlet 2.3 filters. One at:

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Servlets8.html

Essentially, it'll boil down to creating two classes: a filter (implements
javax.servlet.Filter) and a response wrapper (extends
javax.servlet.http.HttpServletResponseWrapper). Then, you'll need to add
 and  elements to web.xml.
How would you determine if a request originated from your search engine?
User-Agent header? Specific request parameter?
Quoting Brice Ruth <[EMAIL PROTECTED]>:

 

Kris,

Thanks for the response. I saw that I could do the opposite :) - no help 
there. I'd be really interested in pursuing your second suggestion. 
Ideally, I'd see setting up a filter that processes every incoming 
request and determines if its originating from our search engine, if so, 
then no-op those methods, otherwise leave everything as is ...

How exactly would I go about doing what you suggest? I've only been 
doing Java/Servlet stuff for about a year or so, and that mostly via 
JSP/Struts/etc. - so I'm no expert when it comes to this.

Kris Schneider wrote:

   

NAFAIK, but that's by no means definitive. I *do* know that you can
 

configure a
   

TC context (or default context) to do the opposite. In other words, turn
 

off
   

cookies and only use rewriting.

Hm, what if you create a filter to wrap the response with an
HttpServletResponseWrapper that no-ops encodeUrl and encodeURL?
Quoting Brice Ruth <[EMAIL PROTECTED]>:



 

Is there any way to disable URL rewriting (with jsessionid) in Tomcat or 
via struts-config.xml or anything? I'm about at my wits end with this 
jsessionid thing - now our search engine which indexes by crawling the 
site (and doesn't support cookies) can't index properly because of the 
jsessionid property ... and frankly, I'm not really caring at this point 
if the 3-5% of visitors to our site can't use sessions (there's 
practically no functionality that depends on it anyway - mainly a 
performance improvement, where it is being used). I'd like to leave 
sessions via cookies enabled, but disable URL rewriting for sessions.

--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.
  

   



 

--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.
   

 

--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Disable URL-rewriting?

[Brice Ruth]

Kris,

Nevermind - I see your link has info on this, too - I'll let the list 
know how this goes.

Brice

Brice Ruth wrote:

I'd probably do a User-Agent header check ...

Now, I've got a Filter already doing some things for the site - so I 
know how to configure web.xml and such, what do I need to do to use 
HttpServletResponseWrapper?

Brice

Kris Schneider wrote:

First, check out a tutorial on Servlet 2.3 filters. One at:

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Servlets8.html

Essentially, it'll boil down to creating two classes: a filter 
(implements
javax.servlet.Filter) and a response wrapper (extends
javax.servlet.http.HttpServletResponseWrapper). Then, you'll need to add
 and  elements to web.xml.

How would you determine if a request originated from your search engine?
User-Agent header? Specific request parameter?
Quoting Brice Ruth <[EMAIL PROTECTED]>:

 

Kris,

Thanks for the response. I saw that I could do the opposite :) - no 
help there. I'd be really interested in pursuing your second 
suggestion. Ideally, I'd see setting up a filter that processes 
every incoming request and determines if its originating from our 
search engine, if so, then no-op those methods, otherwise leave 
everything as is ...

How exactly would I go about doing what you suggest? I've only been 
doing Java/Servlet stuff for about a year or so, and that mostly via 
JSP/Struts/etc. - so I'm no expert when it comes to this.

Kris Schneider wrote:

  

NAFAIK, but that's by no means definitive. I *do* know that you can

configure a
  

TC context (or default context) to do the opposite. In other words, 
turn

off
  

cookies and only use rewriting.

Hm, what if you create a filter to wrap the response with an
HttpServletResponseWrapper that no-ops encodeUrl and encodeURL?
Quoting Brice Ruth <[EMAIL PROTECTED]>:





Is there any way to disable URL rewriting (with jsessionid) in 
Tomcat or via struts-config.xml or anything? I'm about at my wits 
end with this jsessionid thing - now our search engine which 
indexes by crawling the site (and doesn't support cookies) can't 
index properly because of the jsessionid property ... and frankly, 
I'm not really caring at this point if the 3-5% of visitors to our 
site can't use sessions (there's practically no functionality that 
depends on it anyway - mainly a performance improvement, where it 
is being used). I'd like to leave sessions via cookies enabled, 
but disable URL rewriting for sessions.

--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.
 
  



--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.
  


 


--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Disable URL-rewriting?

[Brice Ruth]

I'd probably do a User-Agent header check ...

Now, I've got a Filter already doing some things for the site - so I 
know how to configure web.xml and such, what do I need to do to use 
HttpServletResponseWrapper?

Brice

Kris Schneider wrote:

First, check out a tutorial on Servlet 2.3 filters. One at:

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Servlets8.html

Essentially, it'll boil down to creating two classes: a filter (implements
javax.servlet.Filter) and a response wrapper (extends
javax.servlet.http.HttpServletResponseWrapper). Then, you'll need to add
 and  elements to web.xml.
How would you determine if a request originated from your search engine?
User-Agent header? Specific request parameter?
Quoting Brice Ruth <[EMAIL PROTECTED]>:

 

Kris,

Thanks for the response. I saw that I could do the opposite :) - no help 
there. I'd be really interested in pursuing your second suggestion. 
Ideally, I'd see setting up a filter that processes every incoming 
request and determines if its originating from our search engine, if so, 
then no-op those methods, otherwise leave everything as is ...

How exactly would I go about doing what you suggest? I've only been 
doing Java/Servlet stuff for about a year or so, and that mostly via 
JSP/Struts/etc. - so I'm no expert when it comes to this.

Kris Schneider wrote:

   

NAFAIK, but that's by no means definitive. I *do* know that you can
 

configure a
   

TC context (or default context) to do the opposite. In other words, turn
 

off
   

cookies and only use rewriting.

Hm, what if you create a filter to wrap the response with an
HttpServletResponseWrapper that no-ops encodeUrl and encodeURL?
Quoting Brice Ruth <[EMAIL PROTECTED]>:



 

Is there any way to disable URL rewriting (with jsessionid) in Tomcat or 
via struts-config.xml or anything? I'm about at my wits end with this 
jsessionid thing - now our search engine which indexes by crawling the 
site (and doesn't support cookies) can't index properly because of the 
jsessionid property ... and frankly, I'm not really caring at this point 
if the 3-5% of visitors to our site can't use sessions (there's 
practically no functionality that depends on it anyway - mainly a 
performance improvement, where it is being used). I'd like to leave 
sessions via cookies enabled, but disable URL rewriting for sessions.

--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.
  

   



 

--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.
   

 

--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Disable URL-rewriting?

[Christian Bollmeyer]

Am Dienstag, 18. November 2003 18:29 schrieb Brice Ruth:

If anyone knows a solution to this matter, I'm definitely interested
in hearing about it, too. From all what I can tell, some search
engines don't care (Altavista's Scooter, for example), while
some do (Google, in particular) and go away when they detect
a session. I experimented for quite some time, but to no
real avail. One approach I tried is having a custom action
explicitly killing all sessions when entering the main page
and invoking that one from my index.jsp. This works, but
I couldn't keep to this approach when porting (my private
site) to Tiles some time ago, didn't look further into the
possible reasons behind this. Plus, Struts also stores
some info in session scope, the user's locale, for example.
When I had to decide between sessions and Google
(in fact, I only need sessions for pages 'beyond' authen-
tication stage; my provider doesn't grant me access to
resin.conf, so I had to write a filter for that task), I decided
to better stick to the framework and have Google satisfied
otherwise (ah, robots.txt doesn't make any difference
in this direction, too). Gone bad already, I chose the
cloaking approach (don't try this at home :-), so I changed
my index.jsp to something like:

<%@ page contentType="text/html; charset=ISO-8859-1" session="false" %>
<% String userAgent = request.getHeader("User-Agent");
   if (userAgent.indexOf("oogle") == -1) { %>
  
<% } else { %>
  
<% } %>

and just saved a static snapshot of the main page in 
/static with Cookies enabled, so the jsessionid things are
not appended to the links. Google won't be able
to tell the difference because of the forward.
Considering 'brute' means as disabling URL
rewriting in general, I'd rather guess this is a
server-specific thing. In Java, you don't have
any means of telling the server how to maintain
session state, the only thing you can say is
'request.getSession()' and check for an existing
session if you give 'false' as a parameter to
the overloaded version, and you can 
programmatically kill sessions via
session.invalidate(). This is all Struts can do,
too. So I think you have to check your
server's manuals on this matter. If it's Tomcat,
I can rather reliably tell that you can decide
whether to use cookies or not, but the same
is not true for the URL-rewriting approach
as a 'fallback' means, and then, the server
has to adhere the Servlet specification, after
all. Now. As you can't determine *how* sessions
are maintained, you can still determine to some
degree *when* they're created. One thing I
can tell from my experiences with Struts is that
using the standard forward Action will auto-
matically result in having a session around
afterwards, but if you write a custom one
that just says 'return mapping.findForward("success");,
things are quite different. And so on. I really
have to look further into this if my time allows.

Note this is just telling from my experiences
when developing my private site. On the
job, the landing sites usually are static
HTML pages, not so much because of
session handling or search engines,
but because of the general vulnerability
of dynamic pages to DoS attacks and
high traffic volumes in general.

HTH,
-- Chris. 


> Is there any way to disable URL rewriting (with jsessionid) in Tomcat
> or via struts-config.xml or anything? I'm about at my wits end with
> this jsessionid thing - now our search engine which indexes by
> crawling the site (and doesn't support cookies) can't index properly
> because of the jsessionid property ... and frankly, I'm not really
> caring at this point if the 3-5% of visitors to our site can't use
> sessions (there's practically no functionality that depends on it
> anyway - mainly a performance improvement, where it is being used).
> I'd like to leave sessions via cookies enabled, but disable URL
> rewriting for sessions.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Disable URL-rewriting?

[Kris Schneider]

First, check out a tutorial on Servlet 2.3 filters. One at:

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Servlets8.html

Essentially, it'll boil down to creating two classes: a filter (implements
javax.servlet.Filter) and a response wrapper (extends
javax.servlet.http.HttpServletResponseWrapper). Then, you'll need to add
 and  elements to web.xml.

How would you determine if a request originated from your search engine?
User-Agent header? Specific request parameter?

Quoting Brice Ruth <[EMAIL PROTECTED]>:

> Kris,
> 
> Thanks for the response. I saw that I could do the opposite :) - no help 
> there. I'd be really interested in pursuing your second suggestion. 
> Ideally, I'd see setting up a filter that processes every incoming 
> request and determines if its originating from our search engine, if so, 
> then no-op those methods, otherwise leave everything as is ...
> 
> How exactly would I go about doing what you suggest? I've only been 
> doing Java/Servlet stuff for about a year or so, and that mostly via 
> JSP/Struts/etc. - so I'm no expert when it comes to this.
> 
> Kris Schneider wrote:
> 
> >NAFAIK, but that's by no means definitive. I *do* know that you can
> configure a
> >TC context (or default context) to do the opposite. In other words, turn
> off
> >cookies and only use rewriting.
> >
> >Hm, what if you create a filter to wrap the response with an
> >HttpServletResponseWrapper that no-ops encodeUrl and encodeURL?
> >
> >Quoting Brice Ruth <[EMAIL PROTECTED]>:
> >
> >  
> >
> >>Is there any way to disable URL rewriting (with jsessionid) in Tomcat or 
> >>via struts-config.xml or anything? I'm about at my wits end with this 
> >>jsessionid thing - now our search engine which indexes by crawling the 
> >>site (and doesn't support cookies) can't index properly because of the 
> >>jsessionid property ... and frankly, I'm not really caring at this point 
> >>if the 3-5% of visitors to our site can't use sessions (there's 
> >>practically no functionality that depends on it anyway - mainly a 
> >>performance improvement, where it is being used). I'd like to leave 
> >>sessions via cookies enabled, but disable URL rewriting for sessions.
> >>
> >>-- 
> >>Brice D. Ruth
> >>Sr. IT Analyst
> >>Fiskars Brands, Inc.
> >>
> >>
> >
> >  
> >
> 
> -- 
> Brice D. Ruth
> Sr. IT Analyst
> Fiskars Brands, Inc.

-- 
Kris Schneider <mailto:[EMAIL PROTECTED]>
D.O.Tech   <http://www.dotech.com/>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Disable URL-rewriting?

[Brice Ruth]

Kris,

Thanks for the response. I saw that I could do the opposite :) - no help 
there. I'd be really interested in pursuing your second suggestion. 
Ideally, I'd see setting up a filter that processes every incoming 
request and determines if its originating from our search engine, if so, 
then no-op those methods, otherwise leave everything as is ...

How exactly would I go about doing what you suggest? I've only been 
doing Java/Servlet stuff for about a year or so, and that mostly via 
JSP/Struts/etc. - so I'm no expert when it comes to this.

Kris Schneider wrote:

NAFAIK, but that's by no means definitive. I *do* know that you can configure a
TC context (or default context) to do the opposite. In other words, turn off
cookies and only use rewriting.
Hm, what if you create a filter to wrap the response with an
HttpServletResponseWrapper that no-ops encodeUrl and encodeURL?
Quoting Brice Ruth <[EMAIL PROTECTED]>:

 

Is there any way to disable URL rewriting (with jsessionid) in Tomcat or 
via struts-config.xml or anything? I'm about at my wits end with this 
jsessionid thing - now our search engine which indexes by crawling the 
site (and doesn't support cookies) can't index properly because of the 
jsessionid property ... and frankly, I'm not really caring at this point 
if the 3-5% of visitors to our site can't use sessions (there's 
practically no functionality that depends on it anyway - mainly a 
performance improvement, where it is being used). I'd like to leave 
sessions via cookies enabled, but disable URL rewriting for sessions.

--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.
   

 

--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Disable URL-rewriting?

[Kris Schneider]

NAFAIK, but that's by no means definitive. I *do* know that you can configure a
TC context (or default context) to do the opposite. In other words, turn off
cookies and only use rewriting.

Hm, what if you create a filter to wrap the response with an
HttpServletResponseWrapper that no-ops encodeUrl and encodeURL?

Quoting Brice Ruth <[EMAIL PROTECTED]>:

> Is there any way to disable URL rewriting (with jsessionid) in Tomcat or 
> via struts-config.xml or anything? I'm about at my wits end with this 
> jsessionid thing - now our search engine which indexes by crawling the 
> site (and doesn't support cookies) can't index properly because of the 
> jsessionid property ... and frankly, I'm not really caring at this point 
> if the 3-5% of visitors to our site can't use sessions (there's 
> practically no functionality that depends on it anyway - mainly a 
> performance improvement, where it is being used). I'd like to leave 
> sessions via cookies enabled, but disable URL rewriting for sessions.
> 
> -- 
> Brice D. Ruth
> Sr. IT Analyst
> Fiskars Brands, Inc.

-- 
Kris Schneider <mailto:[EMAIL PROTECTED]>
D.O.Tech   <http://www.dotech.com/>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Disable URL-rewriting?

[Brice Ruth]

Is there any way to disable URL rewriting (with jsessionid) in Tomcat or 
via struts-config.xml or anything? I'm about at my wits end with this 
jsessionid thing - now our search engine which indexes by crawling the 
site (and doesn't support cookies) can't index properly because of the 
jsessionid property ... and frankly, I'm not really caring at this point 
if the 3-5% of visitors to our site can't use sessions (there's 
practically no functionality that depends on it anyway - mainly a 
performance improvement, where it is being used). I'd like to leave 
sessions via cookies enabled, but disable URL rewriting for sessions.

--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

URL Rewriting

[Vikram Goyal]

Hello all,

A curious, but not totally unexpected, thing happens when I try to access my
Apache httpd-Tomcat (4.1.24) site for the first time via mod_jk2 connector.
Since Tomcat/Struts resorts to a URL rewrite of every link (because it
doesn't know that the browser is going to accept a cookie the first time),
all the static data is also appended with the URL rewrite since I am using
the Struts  and  tags. Somehow, the browser is not
able to resolve these URL rewritten links. Does anyone know why this would
be the case? If I do a refresh of the page, the images and other data is
retrieved successfully. If I run the site directly, i.e., on port 8080 on
which Tomcat is running, the data is retrieved without any problem even in
the first go.

If I remove the  tag and replace it with  tag and in essence
take out URL rewritting from the static data, that also works fine.

Any help, pointers appreciated.

Regards,
Vikram


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

URL Rewriting within a FRAMESET

[Martin . Ramsel]

Hallo,

I'm using a frameset in my struts-framework-application.
Everthing workes fine, while cookies an enabled.
If cookies are disabled, the second and third frame don't know the session.

Is there a way to manage it? Or is it even impossible?

kind regards

M.Ramsel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Turning off jsessionid= in URL rewriting

[Dhruva B. Reddy]

I've been battling this myself (we're using IIS and Tomcat 4.1).  We
accept credit cards and enabling cookies was the only way we could get
the session to survive the switch from HTTP to HTTPS and back.

You have to enable cookies at the context level.  You do this in
server.xml.  If you haven't defined a context in this file, that means
you are using the default context.

Unfortunately, I don't have the exact syntax on me at the moment (I
will when I go to work tomorrow if you haven't resolved this by then).

It's an attribute of the Context or DefaultContext element, something
like this:



This will automatically enable cookies with browsers that support/allow
them.

Dhruva

--- Paul Legato <[EMAIL PROTECTED]> wrote:
> Hi,
> I have a client who is requiring that I turn off all the 
> ;jsessionid=abc123etc. session persistance tags in the URL rewriting.
> 
> Unfortunately, I can't find any documentation on how to do this. 
> 
> Is there an easy way to disable these tags across an entire
> application 
> (preferably without forking the Struts code)?
> 
> Thanks,
> -Paul
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Turning off jsessionid= in URL rewriting

[Steve]

It just so happens I just finished dealing with this myself. I found no
answers on the Internet, and I could not find any Struts code I could hack.
But I did solve the issue in my case.

My customer was using IIS which gagged on the ";" in the jessionid.

If you are using Resin, you are lucky as you can turn-off url-rewriting in
the resin.conf. I don't know about Tomcat, and my customer was using JRun
which did not have this option. (In fact, we are using ColdFusionMX .cfm's
instead of JSP's for our views! but that's another story ;)

My work around - for any IIS users out there - was to create in IIS a
virtualDirectory called "PhotoAlbum" which pointed to my Struts directory. I
then created a mapping for extentions ".*" to pass control to the servlet
engine. (The Verify File Exists option must be UN-checked for this to work).
In my struts-config, my forwards use this virtual directory (ie
path="/PhotoAlbum/main.cfm") so that IIS will see the virutal directory and
pass control to the server engine before IIS has a chance to gag on the ";".

Hope this info helps someone out there ;)

Steve B.
- Original Message -
From: "John Loring" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, July 16, 2003 6:04 PM
Subject: Re: Turning off jsessionid= in URL rewriting


> Paul,
>
> This is handled by the application server, so you'll have to turn it off
there.  Usually there are settings for enabling/disabling session
persistence using cookies and/or url rewriting.  Exactly where you'll find
them is dependent on the particular app server you are using. It's not
controlled by struts.  If you use sessions in your application, shutting off
the jsessionid url rewriting will cause problems running on browsers with
cookies disabled.
>
> --John Loring
>
> Paul Legato wrote:
> >
> > Hi,
> > I have a client who is requiring that I turn off all the
> > ;jsessionid=abc123etc. session persistance tags in the URL rewriting.
> > Unfortunately, I can't find any documentation on how to do this.
> >
> > Is there an easy way to disable these tags across an entire application
> > (preferably without forking the Struts code)?
> >
> > Thanks,
> > -Paul
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Turning off jsessionid= in URL rewriting

[Paul Legato]

John,
I'm using Tomcat. I haven't found any setting for disabling these tags in its 
configuration; do you have any idea if Tomcat supports this?

I understand that making an API call into the container is necessary within 
the Struts taglib code to perform the URL rewriting. Is there is a way to 
turn off this API call at the Struts level, maybe via some configuration 
variable?

I know it'll cause problems with cookie-less browsers, and I've explained this 
to the clients. They've decided that most end users will not have disabled 
cookies, and that we should just print a message saying 'cookies are required 
to use this site' if a user has cookies turned off. Not my call, I just write 
the code. :)

-Paul


On Wednesday 16 July 2003 06:04 pm, John Loring wrote:
> Paul,
>
> This is handled by the application server, so you'll have to turn it off
> there.  Usually there are settings for enabling/disabling session
> persistence using cookies and/or url rewriting.  Exactly where you'll find
> them is dependent on the particular app server you are using. It's not
> controlled by struts.  If you use sessions in your application, shutting
> off the jsessionid url rewriting will cause problems running on browsers
> with cookies disabled.
>
> --John Loring
>
> Paul Legato wrote:
> > Hi,
> > I have a client who is requiring that I turn off all the
> > ;jsessionid=abc123etc. session persistance tags in the URL rewriting.
> > Unfortunately, I can't find any documentation on how to do this.
> >
> > Is there an easy way to disable these tags across an entire application
> > (preferably without forking the Struts code)?
> >
> > Thanks,
> > -Paul
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Turning off jsessionid= in URL rewriting

[John Loring]

Paul,

This is handled by the application server, so you'll have to turn it off there.  
Usually there are settings for enabling/disabling session persistence using cookies 
and/or url rewriting.  Exactly where you'll find them is dependent on the particular 
app server you are using. It's not controlled by struts.  If you use sessions in your 
application, shutting off the jsessionid url rewriting will cause problems running on 
browsers with cookies disabled.

--John Loring

Paul Legato wrote:
> 
> Hi,
> I have a client who is requiring that I turn off all the
> ;jsessionid=abc123etc. session persistance tags in the URL rewriting.
> Unfortunately, I can't find any documentation on how to do this.
> 
> Is there an easy way to disable these tags across an entire application
> (preferably without forking the Struts code)?
> 
> Thanks,
> -Paul
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Turning off jsessionid= in URL rewriting

[Paul Legato]

Hi,
I have a client who is requiring that I turn off all the 
;jsessionid=abc123etc. session persistance tags in the URL rewriting. 
Unfortunately, I can't find any documentation on how to do this. 

Is there an easy way to disable these tags across an entire application 
(preferably without forking the Struts code)?

Thanks,
-Paul


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [struts-menu] how to use URL rewriting ?

[Nicolas De Loof]

Thanks a lot.

Nico.

> I wrote a MenuDispalyer that can be configured in a properties file.
> It will not solve your problem but it show how you can write your own
> MenuDisplayer to add replacement variable you need.
> It will require you to retrieve the session id from the pageContext and then
> pass it as a parameter for message resource replacement.
>
> If you are interested by my code look at the patch section of the
> sourceforge account of Struts-Menu where I posted it as
> RecursiveMenuDisplayer. Then look at
> RecusrsiveMenuDisplayer.getDisplayString(String key, String content,
> MenuComponent menu)
> to see how the variable are prepared.
>
> Malik.
>
> Thursday, June 19, 2003 4:10 PM , Nicolas De Loof
> <[EMAIL PROTECTED]> a écrit :
> > The problem we have is that URL are set in menu-config.xml, and
> > struts-menu use it to set links in DHTML menu.
> >
> > Thank you for your help.
> >
> > Nico.
> >
> >
> > > Try  > > http://jakarta.apache.org/struts/userGuide/dev_html.html
> > >
> > > > From: "Nicolas De Loof" <[EMAIL PROTECTED]>
> > > > Reply-To: "Struts Users Mailing List"
> > > > <[EMAIL PROTECTED]> To: "Struts Users Mailing List"
> > > > <[EMAIL PROTECTED]> Subject: [struts-menu] how to
> > > > use URL rewriting ? Date: Thu, 19 Jun 2003 15:53:56 +0200
> > > >
> > > > Hi all,
> > > >
> > > > our application uses URL rewriting to track session (for some
> > > > obscure reasons...)
> > > > We use struts-menu taglib, and it doesn't "urlrewrite" links in
> > > > menu items.
> > > >
> > > > From what I've seen in struts-menu sources, it is not possible
> > > > because MenuDisplayer doesn't have any HttpResponse
> > > > param. Do you know any struts-menu extension or patch that uses
> > > > response.encodeURL() ?
> > > >
> > > > Nico.
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail:
> > > > [EMAIL PROTECTED]
> > > >
> > >
> > > _
> > > MSN 8 with e-mail virus protection service: 2 months FREE*
> > > http://join.msn.com/?page=features/virus
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [struts-menu] how to use URL rewriting ?

[Malik Recoing]

I wrote a MenuDispalyer that can be configured in a properties file.
It will not solve your problem but it show how you can write your own
MenuDisplayer to add replacement variable you need.
It will require you to retrieve the session id from the pageContext and then
pass it as a parameter for message resource replacement.

If you are interested by my code look at the patch section of the
sourceforge account of Struts-Menu where I posted it as
RecursiveMenuDisplayer. Then look at
RecusrsiveMenuDisplayer.getDisplayString(String key, String content,
MenuComponent menu)
to see how the variable are prepared.

Malik.

Thursday, June 19, 2003 4:10 PM , Nicolas De Loof
<[EMAIL PROTECTED]> a écrit :
> The problem we have is that URL are set in menu-config.xml, and
> struts-menu use it to set links in DHTML menu.
>
> Thank you for your help.
>
> Nico.
>
>
> > Try  > http://jakarta.apache.org/struts/userGuide/dev_html.html
> >
> > > From: "Nicolas De Loof" <[EMAIL PROTECTED]>
> > > Reply-To: "Struts Users Mailing List"
> > > <[EMAIL PROTECTED]> To: "Struts Users Mailing List"
> > > <[EMAIL PROTECTED]> Subject: [struts-menu] how to
> > > use URL rewriting ? Date: Thu, 19 Jun 2003 15:53:56 +0200
> > >
> > > Hi all,
> > >
> > > our application uses URL rewriting to track session (for some
> > > obscure reasons...)
> > > We use struts-menu taglib, and it doesn't "urlrewrite" links in
> > > menu items.
> > >
> > > From what I've seen in struts-menu sources, it is not possible
> > > because MenuDisplayer doesn't have any HttpResponse
> > > param. Do you know any struts-menu extension or patch that uses
> > > response.encodeURL() ?
> > >
> > > Nico.
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail:
> > > [EMAIL PROTECTED]
> > >
> >
> > _
> > MSN 8 with e-mail virus protection service: 2 months FREE*
> > http://join.msn.com/?page=features/virus
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [struts-menu] how to use URL rewriting ?

[Nicolas De Loof]

The problem we have is that URL are set in menu-config.xml, and struts-menu use it to 
set links in DHTML menu.

Thank you for your help.

Nico.


> Try  http://jakarta.apache.org/struts/userGuide/dev_html.html
> 
> >From: "Nicolas De Loof" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >Subject: [struts-menu] how to use URL rewriting ?
> >Date: Thu, 19 Jun 2003 15:53:56 +0200
> >
> >Hi all,
> >
> >our application uses URL rewriting to track session (for some obscure 
> >reasons...)
> >We use struts-menu taglib, and it doesn't "urlrewrite" links in menu items.
> >
> >From what I've seen in struts-menu sources, it is not possible because 
> >MenuDisplayer doesn't have any HttpResponse
> >param. Do you know any struts-menu extension or patch that uses 
> >response.encodeURL() ?
> >
> >Nico.
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> _
> MSN 8 with e-mail virus protection service: 2 months FREE*  
> http://join.msn.com/?page=features/virus
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [struts-menu] how to use URL rewriting ?

[Ben Anderson]

Try http://jakarta.apache.org/struts/userGuide/dev_html.html
From: "Nicolas De Loof" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Subject: [struts-menu] how to use URL rewriting ?
Date: Thu, 19 Jun 2003 15:53:56 +0200
Hi all,

our application uses URL rewriting to track session (for some obscure 
reasons...)
We use struts-menu taglib, and it doesn't "urlrewrite" links in menu items.

From what I've seen in struts-menu sources, it is not possible because 
MenuDisplayer doesn't have any HttpResponse
param. Do you know any struts-menu extension or patch that uses 
response.encodeURL() ?

Nico.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[struts-menu] how to use URL rewriting ?

[Nicolas De Loof]

Hi all,

our application uses URL rewriting to track session (for some obscure reasons...)
We use struts-menu taglib, and it doesn't "urlrewrite" links in menu items.

>From what I've seen in struts-menu sources, it is not possible because MenuDisplayer 
>doesn't have any HttpResponse
param. Do you know any struts-menu extension or patch that uses response.encodeURL() ?

Nico.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: url rewriting

[SA]

I think you can use html:rewrite.

','TestWindow',

'toolbar=no,location=no,directories=no,status=yes,menubar=no,scrollbars=yes,
 resizable=no, width=620,height=250,left=20,top=20'); return
false;">
 Test Link

Richard Raquepo wrote:

> yes by using the html:link , but i want to control the size of the created
> window? how can it be done?
> - Original Message -
> From: "Claude Betancourt" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Thursday, April 03, 2003 1:51 PM
> Subject: Re: url rewriting
>
> > the session is attached to the browser instance and not the individual
> > window, so by popping a new window with a new action you'll carry the same
> > session attributes without the need to specify the session id.
> > -c
> >
> > - Original Message -
> > From: "Richard Raquepo" <[EMAIL PROTECTED]>
> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > Sent: Thursday, April 03, 2003 12:56 AM
> > Subject: url rewriting
> >
> >
> > i have this kind of link that will open a new window:
> >
> >  > onClick="TestWindow=window.open('?LINK.do?','TestWindow',
> >
> 'toolbar=no,location=no,directories=no,status=yes,menubar=no,scrollbars=yes,
> > resizable=no, width=620,height=250,left=20,top=20'); return
> false;">
> > Test Link
> >
> > i wan't to be able to transfer my current session to the new browser? what
> > tag should i use so that i can passed the current sessionid in the
> ?LINK.do?
> > ?
> >
> > or is it possible to use  tag that has a new window with my
> > parameters in it?
> >
> > thanks a lot...
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

RE: url rewriting

[Andrew Hill]

That only applies if your using cookies to pass the sessionId to the server.
If you are also supporting users without cookies enabled you will still need
to rewrite the url.

-Original Message-
From: Claude Betancourt [mailto:[EMAIL PROTECTED]
Sent: Thursday, 3 April 2003 13:52
To: Struts Users Mailing List
Subject: Re: url rewriting


the session is attached to the browser instance and not the individual
window, so by popping a new window with a new action you'll carry the same
session attributes without the need to specify the session id.
-c

- Original Message -
From: "Richard Raquepo" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, April 03, 2003 12:56 AM
Subject: url rewriting


i have this kind of link that will open a new window:


Test Link

i wan't to be able to transfer my current session to the new browser? what
tag should i use so that i can passed the current sessionid in the ?LINK.do?
?

or is it possible to use  tag that has a new window with my
parameters in it?

thanks a lot...


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: url rewriting

[Richard Raquepo]

yes by using the html:link , but i want to control the size of the created
window? how can it be done?
- Original Message -
From: "Claude Betancourt" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, April 03, 2003 1:51 PM
Subject: Re: url rewriting


> the session is attached to the browser instance and not the individual
> window, so by popping a new window with a new action you'll carry the same
> session attributes without the need to specify the session id.
> -c
>
> - Original Message -
> From: "Richard Raquepo" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Thursday, April 03, 2003 12:56 AM
> Subject: url rewriting
>
>
> i have this kind of link that will open a new window:
>
>  onClick="TestWindow=window.open('?LINK.do?','TestWindow',
>
'toolbar=no,location=no,directories=no,status=yes,menubar=no,scrollbars=yes,
> resizable=no, width=620,height=250,left=20,top=20'); return
false;">
> Test Link
>
> i wan't to be able to transfer my current session to the new browser? what
> tag should i use so that i can passed the current sessionid in the
?LINK.do?
> ?
>
> or is it possible to use  tag that has a new window with my
> parameters in it?
>
> thanks a lot...
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: url rewriting

[Claude Betancourt]

the session is attached to the browser instance and not the individual
window, so by popping a new window with a new action you'll carry the same
session attributes without the need to specify the session id.
-c

- Original Message -
From: "Richard Raquepo" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, April 03, 2003 12:56 AM
Subject: url rewriting


i have this kind of link that will open a new window:


Test Link

i wan't to be able to transfer my current session to the new browser? what
tag should i use so that i can passed the current sessionid in the ?LINK.do?
?

or is it possible to use  tag that has a new window with my
parameters in it?

thanks a lot...


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

url rewriting

[Richard Raquepo]

i have this kind of link that will open a new window:


Test Link

i wan't to be able to transfer my current session to the new browser? what tag should 
i use so that i can passed the current sessionid in the ?LINK.do? ?

or is it possible to use  tag that has a new window with my parameters in 
it?

thanks a lot...

Re: URL Rewriting

[Max Cooper]

You do actually have to go through the pains of rewriting all of your URLs
in links and things for this to work. If you have a link in a page like
this: Lose it! you will lose the session,
since there is no call to rewrite the URL.

I believe that the Struts tags will rewrite the URLs as part of their normal
processing, so they might be very helpful. But you have to use them
consistently! One bad URL in the whole site/app will drop the session if the
user clicks on it.

-Max

- Original Message -
From: "Wendy Cameron" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 19, 2003 6:39 PM
Subject: RE: URL Rewriting


This is what I would have expected, but isnt our experience and I am not
sure why.

Regards Wendy

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 20, 2003 12:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: URL Rewriting
>
>
> My Tomcat 4.1.18 does this automatically if cookies are off.
>
> David
>
>
>
> >From: "Wendy Cameron" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List"
> <[EMAIL PROTECTED]>
> >To: "Struts Users Mailing List (E-mail)"
> <[EMAIL PROTECTED]>
> >Subject: URL Rewriting
> >Date: Thu, 20 Mar 2003 12:36:44 +1000
> >
> >We have come up against a problem with URL re-writing in
> Tomcat, basically
> >what happens is if the user switches off, cookies all
> session information
> >is lost.  We need to have session information even if
> cookies are disabled,
> >is there some options somewhere in Tomcat 4.1.18 to switch on, URL
> >rewriting to put in the session id and do url rewriting
> based session
> >tracking.
> >
> >Regards Wendy
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> _
> Add photos to your messages with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: URL Rewriting

[Wendy Cameron]

This is what I would have expected, but isnt our experience and I am not sure why.

Regards Wendy

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 20, 2003 12:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: URL Rewriting
> 
> 
> My Tomcat 4.1.18 does this automatically if cookies are off.
> 
> David
> 
> 
> 
> >From: "Wendy Cameron" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" 
> <[EMAIL PROTECTED]>
> >To: "Struts Users Mailing List (E-mail)" 
> <[EMAIL PROTECTED]>
> >Subject: URL Rewriting
> >Date: Thu, 20 Mar 2003 12:36:44 +1000
> >
> >We have come up against a problem with URL re-writing in 
> Tomcat, basically 
> >what happens is if the user switches off, cookies all 
> session information 
> >is lost.  We need to have session information even if 
> cookies are disabled, 
> >is there some options somewhere in Tomcat 4.1.18 to switch on, URL 
> >rewriting to put in the session id and do url rewriting 
> based session 
> >tracking.
> >
> >Regards Wendy
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> _
> Add photos to your messages with MSN 8. Get 2 months FREE*.  
> http://join.msn.com/?page=features/featuredemail
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: URL Rewriting

[David Graham]

My Tomcat 4.1.18 does this automatically if cookies are off.

David



From: "Wendy Cameron" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List (E-mail)" <[EMAIL PROTECTED]>
Subject: URL Rewriting
Date: Thu, 20 Mar 2003 12:36:44 +1000
We have come up against a problem with URL re-writing in Tomcat, basically 
what happens is if the user switches off, cookies all session information 
is lost.  We need to have session information even if cookies are disabled, 
is there some options somewhere in Tomcat 4.1.18 to switch on, URL 
rewriting to put in the session id and do url rewriting based session 
tracking.

Regards Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


_
Add photos to your messages with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

URL Rewriting

[Wendy Cameron]

We have come up against a problem with URL re-writing in Tomcat, basically what 
happens is if the user switches off, cookies all session information is lost.  We need 
to have session information even if cookies are disabled, is there some options 
somewhere in Tomcat 4.1.18 to switch on, URL rewriting to put in the session id and do 
url rewriting based session tracking.

Regards Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Association between Session object and Cookies/URL rewriting

[Mohan Radhakrishnan]

Hi,
 It is not CMS. Will take a look at the security filter.
Mohan

-Original Message-
From: Max Cooper [mailto:[EMAIL PROTECTED]
Sent: Friday, March 07, 2003 1:30 PM
To: Struts Users Mailing List
Subject: Re: Association between Session object and Cookies/URL
rewriting


> Requirement is this : My login page itself expires even if the user
> doesn't login for the session timeout period. We want to prevent that.

Hmm... I don't think there is much you can do in that case with
container-managed security. If the user fails to login within the session
expiration time, their session will expire. When the user then submits the
login form, it will look like a spontaneous login to the server, which is
not supported with container-managed security, and will cause an error (on
Tomcat at least; WebLogic does something a little different, but I think the
different behaviors just highlight the reason why depending on this setup is
risky).

The SecurityFilter project supports this kind of operation to some extent.
The session will still expire, so the server will not be able to take the
user directly to the protected page that caused the login form to appear.
But SecurityFilter supports the configuration of a 'default page' to send
the user to if they login without an active session, or simply submit a
login form without being sent there by the filter.
http://securityfilter.sourceforge.net/

-Max



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Association between Session object and Cookies/URL rewriting

[Max Cooper]

> Requirement is this : My login page itself expires even if the user
> doesn't login for the session timeout period. We want to prevent that.

Hmm... I don't think there is much you can do in that case with
container-managed security. If the user fails to login within the session
expiration time, their session will expire. When the user then submits the
login form, it will look like a spontaneous login to the server, which is
not supported with container-managed security, and will cause an error (on
Tomcat at least; WebLogic does something a little different, but I think the
different behaviors just highlight the reason why depending on this setup is
risky).

The SecurityFilter project supports this kind of operation to some extent.
The session will still expire, so the server will not be able to take the
user directly to the protected page that caused the login form to appear.
But SecurityFilter supports the configuration of a 'default page' to send
the user to if they login without an active session, or simply submit a
login form without being sent there by the filter.
http://securityfilter.sourceforge.net/

-Max



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Association between Session object and Cookies/URL rewriting

[Mohan Radhakrishnan]

Hi,

   Actually it is the normal functionality. I was confused a bit.

I've done the following things.

1. I will call session.invalidate()
2. saveOnRestart="false" to prevent writing of session.ser



Requirement is this : My login page itself expires even if the user
doesn't login for the session timeout period. We want to prevent that.

 NO. 2 above is done to prevent tomcat from writing session.ser. I assume
there are no side-effects. The two might not be related. But I thought if
session info. is persisted across shutdowns and restarts I could see old
session data.

Mohan


-Original Message-
From: Max Cooper [mailto:[EMAIL PROTECTED]
Sent: Friday, March 07, 2003 12:18 AM
To: Struts Users Mailing List
Subject: RE: Association between Session object and Cookies/URL
rewriting


I am not sure what the goal is for your application. You only want to
call session.invalidate() if you want the server to forget about the
user (force a logout). What is it that you wish to achieve?

-Max

On Thu, 2003-03-06 at 05:50, Mohan Radhakrishnan wrote:
> 
>  So I will have to use
> 
>   inValidateSession( request );
> 
>  What will happen to code like this in by base action if I do this?
That
> would be lost.
> 
>   protected void setLocale(
> HttpServletRequest request,
> Locale locale) {
> 
> HttpSession session = request.getSession(true);
> session.setAttribute( Action.LOCALE_KEY,locale );
> 
> }
> 
> Mohan
> 
> -Original Message-
> From: Max Cooper [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 06, 2003 6:18 PM
> To: Struts Users Mailing List
> Subject: Re: Association between Session object and Cookies/URL
> rewriting
> 
> 
> >Some login pages and servers may drop your old session when you
> >authenticate, but I know that Tomcat doesn't do that unless you
explicitly
> >have a session.invalidate() call in your login page.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Association between Session object and Cookies/URL rewriting

[Max Cooper]

I am not sure what the goal is for your application. You only want to
call session.invalidate() if you want the server to forget about the
user (force a logout). What is it that you wish to achieve?

-Max

On Thu, 2003-03-06 at 05:50, Mohan Radhakrishnan wrote:
> 
>  So I will have to use
> 
>   inValidateSession( request );
> 
>  What will happen to code like this in by base action if I do this? That
> would be lost.
> 
>   protected void setLocale(
> HttpServletRequest request,
> Locale locale) {
> 
> HttpSession session = request.getSession(true);
> session.setAttribute( Action.LOCALE_KEY,locale );
> 
> }
> 
> Mohan
> 
> -Original Message-
> From: Max Cooper [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 06, 2003 6:18 PM
> To: Struts Users Mailing List
> Subject: Re: Association between Session object and Cookies/URL
> rewriting
> 
> 
> >Some login pages and servers may drop your old session when you
> >authenticate, but I know that Tomcat doesn't do that unless you explicitly
> >have a session.invalidate() call in your login page.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Association between Session object and Cookies/URL rewriting

[Mohan Radhakrishnan]

 So I will have to use

inValidateSession( request );

 What will happen to code like this in by base action if I do this? That
would be lost.

protected void setLocale(
HttpServletRequest request,
Locale locale) {

HttpSession session = request.getSession(true);
session.setAttribute( Action.LOCALE_KEY,locale );

}

Mohan

-Original Message-
From: Max Cooper [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2003 6:18 PM
To: Struts Users Mailing List
Subject: Re: Association between Session object and Cookies/URL
rewriting


>Some login pages and servers may drop your old session when you
>authenticate, but I know that Tomcat doesn't do that unless you explicitly
>have a session.invalidate() call in your login page.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Association between Session object and Cookies/URL rewriting

[Max Cooper]

It sounds like there is something else going on. The session timeout set in
the web.xml file is the time required for the server to totally forget about
you, whether you had authenticated yourself or not. It is the time since
your last request that matters. If the timeout is set for 30 minutes, you
can go to the site, click around for a few hours, and then if you wait more
than 30 minutes before making another request, the server will drop your
session. If you happened to have authenticated yourself, it will forget
about that at the same time that it forgets about your HttpSession stuff.

Some login pages and servers may drop your old session when you
authenticate, but I know that Tomcat doesn't do that unless you explicitly
have a session.invalidate() call in your login page. I tested this by having
a simple app with container-managed authentication where you could edit the
contents of your session with both an unprotected page and a protected page.
If you put stuff in your session and then clicked a link to go to the
protected page, you would be asked to login, and then you would arrive at
the protected page to find that all the stuff you put in the session was
still there.

In the SecurityFilter project (a Filter-based mimic of container-managed
authentication), we did have to handle one exception, and that is that your
session will be dropped if you were previously authenticated in that same
session. So, it won't drop the session on an unauthenticated ->
authenticated transition, but the session will be dropped on an
authenticated -> authenticated transition. We did this to be sure that any
information that might have been stored in the session for the last user is
not available to the new user as a security measure. I don't think that
Tomcat has to account for this issue, since it won't ever send you to login
if you have already authenticated yourself, and will give an error if you
submit a login form without being sent there by Tomcat. I am not sure what
they do with your old session in the case that you send a login request
anyway, but you can't really design your app to work that way since it isn't
supported in the first place. You might just get an error and remain logged
in as the original user, or you might get an error and have your old session
dropped (I am not sure if you would be logged in as the new user or not). In
SecurityFilter, you are allowed to send a login request any time you want by
design, so we had to handle that case.

SecurityFilter project home page (shameless plug :P):
http://securityfilter.sourceforge.net/

-Max

- Original Message -
From: "Mohan Radhakrishnan" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Thursday, March 06, 2003 3:55 AM
Subject: RE: Association between Session object and Cookies/URL rewriting


Hi,
   It seems that there is no way to associate the session timeout
information in the web.xml for the session created after the user logs in.
Or is there ? Let me know if I am very wrong here but my login page also
expires before the user is authenticated. The user perception is that the
application is expiring even before he is authenticated.
Mohan

-Original Message-
From: Gemes Tibor [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2003 5:18 PM
To: Struts Users Mailing List
Subject: Re: Association between Session object and Cookies/URL
rewriting


2003. március 6. 12:10 dátummal Max Cooper ezt írtad:
> Here's a little dialog to illustrate:

Wow! That was marvellous!

Tib

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Association between Session object and Cookies/URL rewriting

[Mohan Radhakrishnan]

Hi,
   It seems that there is no way to associate the session timeout
information in the web.xml for the session created after the user logs in.
Or is there ? Let me know if I am very wrong here but my login page also
expires before the user is authenticated. The user perception is that the
application is expiring even before he is authenticated.
Mohan

-Original Message-
From: Gemes Tibor [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2003 5:18 PM
To: Struts Users Mailing List
Subject: Re: Association between Session object and Cookies/URL
rewriting


2003. március 6. 12:10 dátummal Max Cooper ezt írtad:
> Here's a little dialog to illustrate:

Wow! That was marvellous! 

Tib

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Association between Session object and Cookies/URL rewriting

[Gemes Tibor]

2003. március 6. 12:10 dátummal Max Cooper ezt írtad:
> Here's a little dialog to illustrate:

Wow! That was marvellous! 

Tib

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Association between Session object and Cookies/URL rewriting

[Max Cooper]

Session IDs identify sessions, not users.

A session is using a browser to access a server from a particular machine.
It doesn't matter if you login or not, sessions are meant just to associate
a group of requests as coming from one (or more) person sitting at a
computer using a browser. HTTP is a stateless protocol, meaning the protocol
does not have any built-in way for the server to recognize that several
requests are coming from the same session. By using a session cookie (or URL
rewriting), the server can track which requests should be associated with a
particular session, because all of those requests will include the session
ID.

Here's a little dialog to illustrate:

Ms. Browser (a browser): Hello Mr. Forgetful, please send me the search
form.

Mr. Forgetful (the server): Welcome, please excuse me not remembering who
you are or even if this is your first request or not, but it is not in my
protocol to do so. So that I may handle your requests with the highest level
of service in the future, please include this SessionID cookie that I am
including in your response with your requests. It will help me identify you
in the future and perhaps remember your preferences.

Ms. Browser: I take no offense to you not remembering me, even though I was
just here earlier in the day. I realize it is not in your protocol to do so,
and I do appreciate your efforts with the SessionID cookie. I will be sure
to include it with all my requests. Please perform a search with the
keywords "tattoo parlor".

Mr. Forgetful: A search for "tattoo parlor", eh? I still don't know your
name, but I see that you have visited recently; thank you for including the
SessionID cookie with your request. Here are your search results. I have
included 10 hits per page, as it is the default.

Ms. Browser: Thank you, Mr. Forgetful. Can you please run the search for
"tattoo parlors" again and include 25 hits per page this time?

Mr. Forgetful: A search for "tattoo parlor" with 25 hits per page is coming
your way. I will remember your preference for 25 hits so that I may format
any future searches with the same preference. Thank you for including your
SessionID cookie with your request, and please be sure to include it with
any future requests so that I may apply your preferences.

Ms. Browser: Oh, I see a hit that I would like to view. Please send me
information on Sick Dogs Tattoo Parlor.

Mr. Forgetful: Whoa! That information requires that you identify yourself
before viewing, and I don't have any user information associated with the
SessionID cookie that you sent with your request. Please request the login
form so that I may verify your access. I will remember the page you were
trying to view based on your SessionID for your convenience.

Ms. Browser: You must be sending me on some kind of wild goose chase, Mr.
Forgetful! Please send me the login form.

Mr. Forgetful: Here is the login form, as requested.

Ms. Browser: Okay, my username is 'PaintedLady' and my password is
'Butterfly'.

Mr. Forgetful: Oh hello, PaintedLady! I have associated your user
information with the SessionID cookie that you included with your request.
Please make a new request the Sick Dogs Tattoo Parlor information page
again.

Ms. Broswer: I hope this is the end of this goose chase, Mr. Forgetful!
Please send me the information page on Sick Dogs Tattoo Parlor, please.

Mr. Forgetful: Whoa! Oh nevermind, I see that it is just you, PaintedLady,
based on the user information associated with your SessionID, and I see that
you have sufficient rights for me to process your request. Here is the page
you requested.

Ms. Browser: Thank you, Mr. Forgetful. They have a picture of one of the
tattoos on my back, and I am beginning to think that one was a mistake. I'm
going to back up a bit here. Please do a search for "tattoo removal
service".

Mr. Forgetful: Okay, here are the results for the "tattoo removal service"
search, and based on the preferences I have associated with your SessionID,
I have included 25 hits per page.


Okay, it's kind of a silly dialog. But that is how the SessionID cookie
works, and how it interplays with authentication. Note that the user
information is not directly available in the HttpSession in most cases, but
the server associates both with the SessionID behind the scenes, and your
apps can access it through request.getUserPrinicpal() and
request.getRemoteUser(), request.isUserInRole(), etc. The lifecycle of this
authentication information is the same as that of the HttpSession, since the
server uses the SessionID cookie to identify both pieces of information.
Servers often use a combination of the IP address your requests come from
and perhaps other information along with the SessionID cookie value to
enhance security. The name of the 'SessionID' cookie he

Re: Association between Session object and Cookies/URL rewriting

[Nicolas De Loof]

right, but if you restart your browser, session will be invalidated,
as coockie is (by default) set to a browser instance.

The way coockies are stored on windows (NT) platform has no impact on
session tracking mechanism.

Nico.

> but however if one uses the cookies for saving the sessionId on the
> customer,
> the cookie is saved under a "user" directory
> C:\WINNT\Profiles\\Cookies.
> the  reprensents a physical person for cookie
information, isn't
> it ?
>
>
>
> ---
> As of February 12, 2003 Thomson unifies its email addresses on a
worldwide
> basis.Please note my new email address: [EMAIL PROTECTED]
>
> Thomson is the leader in solutions and technologies for the
entertainment
> and media industries and serves its customers under its four
strategic
> brands: Technicolor, Grass Valley, RCA and THOMSON.
> More about Thomson: http://www.thomson.net/videochain
>
> Original Message-
> From: Nicolas De Loof [mailto:[EMAIL PROTECTED]
> Sent: 06 March 2003 10:32
> To: Struts Users Mailing List
> Subject: Re: Association between Session object and Cookies/URL
> rewriting
>
>
> > I well understand now that Sessions (object on the web server) are
> > used either cookies or URL writing (in the client side).
> > In the struts application I have to make changes if I want to
> > use URL rewriting.
> > But what I still do not understand (I am sorry to be also
insistent)
> is
> > why/or how each user will have a own unique sessionID ?.
> > How a user is identified?
> > What distinguish a client from an other client ?
> > Is the user NT account ?
> > Perhaps a client is not a "physical" person but an instance of Web
> browser ,
> >
>
> A "client" is not a "physical" person but an instance of a browser :
> When J2EE server doesn't get any session info from request (form
> coockie or request parameter if url rewriting is used), it will
> generate a new session id for "client". Every new request from this
> browser will come with sessionid, and a pseudo-connection will be
> maintained between browser and server.
>
> A "user" is indentified by the browser instance it is using.
>
> Nico.
>
>
> 
-
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Association between Session object and Cookies/URL rewriting

[Heligon Sandra]

but however if one uses the cookies for saving the sessionId on the
customer, 
the cookie is saved under a "user" directory
C:\WINNT\Profiles\\Cookies.
the  reprensents a physical person for cookie information, isn't
it ?
 


--- 
As of February 12, 2003 Thomson unifies its email addresses on a worldwide
basis.Please note my new email address: [EMAIL PROTECTED] 

Thomson is the leader in solutions and technologies for the entertainment
and media industries and serves its customers under its four strategic
brands: Technicolor, Grass Valley, RCA and THOMSON. 
More about Thomson: http://www.thomson.net/videochain 

Original Message-
From: Nicolas De Loof [mailto:[EMAIL PROTECTED]
Sent: 06 March 2003 10:32
To: Struts Users Mailing List
Subject: Re: Association between Session object and Cookies/URL
rewriting


> I well understand now that Sessions (object on the web server) are
> used either cookies or URL writing (in the client side).
> In the struts application I have to make changes if I want to
> use URL rewriting.
> But what I still do not understand (I am sorry to be also insistent)
is
> why/or how each user will have a own unique sessionID ?.
> How a user is identified?
> What distinguish a client from an other client ?
> Is the user NT account ?
> Perhaps a client is not a "physical" person but an instance of Web
browser ,
>

A "client" is not a "physical" person but an instance of a browser :
When J2EE server doesn't get any session info from request (form
coockie or request parameter if url rewriting is used), it will
generate a new session id for "client". Every new request from this
browser will come with sessionid, and a pseudo-connection will be
maintained between browser and server.

A "user" is indentified by the browser instance it is using.

Nico.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Association between Session object and Cookies/URL rewriting

[Mohan Radhakrishnan]

Hi,
   I looked at all the conditions in Craig's mail that you included.

  *   Actions will create a session for you automatically if you use
transaction tokens, or the getLocale()/setLocale() methods.

   My BaseAction that my LoginAction extends has code like this.

protected void setLocale(
HttpServletRequest request,
Locale locale) {

HttpSession session = request.getSession(true);
session.setAttribute( Action.LOCALE_KEY,locale );

}

My login page expires after the session timeout period even before the user
logs in . So I thought that since a new session is already created (
according to the above mentioned point ) and I am using request.getSession()
( not request.getSession( true ) ) and the setLocale method it is normal for
the login page itself to expire.

  Is that right ?

Mohan

-Original Message-
From: Heligon Sandra [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2003 2:55 PM
To: 'Struts Users Mailing List'
Subject: RE: Association between Session object and Cookies/URL
rewriting


I well understand now that Sessions (object on the web server) are
used either cookies or URL writing (in the client side).
In the struts application I have to make changes if I want to
use URL rewriting.
But what I still do not understand (I am sorry to be also insistent) is
why/or how each user will have a own unique sessionID ?.
How a user is identified? 
What distinguish a client from an other client ?
Is the user NT account ?
Perhaps a client is not a "physical" person but an instance of Web browser ,

is this as that which should be heard it ?

Mohan, could you explain me "I am using setLocale in the base action".
I don't understand well what setLocale allows? 


--- 
As of February 12, 2003 Thomson unifies its email addresses on a worldwide
basis.Please note my new email address: [EMAIL PROTECTED] 

Thomson is the leader in solutions and technologies for the entertainment
and media industries and serves its customers under its four strategic
brands: Technicolor, Grass Valley, RCA and THOMSON. 
More about Thomson: http://www.thomson.net/videochain 

Original Message-
From: Andrew Hill [mailto:[EMAIL PROTECTED]
Sent: 06 March 2003 10:07
To: Struts Users Mailing List
Subject: RE: Association between Session object and Cookies/URL
rewriting


HttpSession is a seperate matter from authentication as far as the container
is concerned, in as much as session tracking operates to associate requests
with a particular client. The way it does this is by allocated a session
id - which the client submits with each request.

There are two ways that this id can be submitted.
The first (and I believe the default) is to make use of cookies. If the
container is giving the client a session and the client has cookies enabled,
the container will return to the client a cookie that contains the session
id, and the client borwser submits this with its requests allowing the
container to identify which session the request belongs to. This mechanism
works almost transparently both to the user and the developer.

The second way - url rewriting - operates when cookies are disabled on the
client (and it is considered best practise to allow for this possibility as
a lot of users are getting paranoid about cookies these days). This involves
all links that are displayed in the browser including the session id as part
of the url - so you will see urls of the form:
http://www.mystery-machine.com/shaggy/scooby.do;jsessionid=4878D95252DE47FDC
39E69070F49F397

Obviously for the links to contain the session id the developer has to do a
bit more work - basically requiring all links to pages/actions participating
in that session to be 'rewritten'. The struts  tag will do this
for any links you render with it automatically, - I presume the 
tag will also do it for its action (I dont use jsp so arent entirely sure
but it would seem logical).

If you need to do it yourself somewhere the servlet apis HttpServletResponse
also supplies an encodeUrl() method that when passed a string containing a
plain url will add the session id if necessary and return the encoded url
string to you.


-Original Message-
From: Heligon Sandra [mailto:[EMAIL PROTECTED]
Sent: Thursday, 6 March 2003 16:41
To: 'Struts Users Mailing List'
Subject: RE: Association between Session object and Cookies/URL
rewriting
Importance: High


Tomcat is responsible of the cookie creation but it is
the Struts Action Servlet that is responsible of the
session (HttpSession initialization) isn't it ?
A few months ago I had had a discussion with Craig and it had indicated
to me that a session was initialized in several cases:

* The controller servlet will create a session for you, if you
  declare that your form bean is in session scope.

* The controller servlet will create a sess

Re: Association between Session object and Cookies/URL rewriting

[Nicolas De Loof]

> I well understand now that Sessions (object on the web server) are
> used either cookies or URL writing (in the client side).
> In the struts application I have to make changes if I want to
> use URL rewriting.
> But what I still do not understand (I am sorry to be also insistent)
is
> why/or how each user will have a own unique sessionID ?.
> How a user is identified?
> What distinguish a client from an other client ?
> Is the user NT account ?
> Perhaps a client is not a "physical" person but an instance of Web
browser ,
>

A "client" is not a "physical" person but an instance of a browser :
When J2EE server doesn't get any session info from request (form
coockie or request parameter if url rewriting is used), it will
generate a new session id for "client". Every new request from this
browser will come with sessionid, and a pseudo-connection will be
maintained between browser and server.

A "user" is indentified by the browser instance it is using.

Nico.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Association between Session object and Cookies/URL rewriting

[Heligon Sandra]

I well understand now that Sessions (object on the web server) are
used either cookies or URL writing (in the client side).
In the struts application I have to make changes if I want to
use URL rewriting.
But what I still do not understand (I am sorry to be also insistent) is
why/or how each user will have a own unique sessionID ?.
How a user is identified? 
What distinguish a client from an other client ?
Is the user NT account ?
Perhaps a client is not a "physical" person but an instance of Web browser ,

is this as that which should be heard it ?

Mohan, could you explain me "I am using setLocale in the base action".
I don't understand well what setLocale allows? 


--- 
As of February 12, 2003 Thomson unifies its email addresses on a worldwide
basis.Please note my new email address: [EMAIL PROTECTED] 

Thomson is the leader in solutions and technologies for the entertainment
and media industries and serves its customers under its four strategic
brands: Technicolor, Grass Valley, RCA and THOMSON. 
More about Thomson: http://www.thomson.net/videochain 

Original Message-
From: Andrew Hill [mailto:[EMAIL PROTECTED]
Sent: 06 March 2003 10:07
To: Struts Users Mailing List
Subject: RE: Association between Session object and Cookies/URL
rewriting


HttpSession is a seperate matter from authentication as far as the container
is concerned, in as much as session tracking operates to associate requests
with a particular client. The way it does this is by allocated a session
id - which the client submits with each request.

There are two ways that this id can be submitted.
The first (and I believe the default) is to make use of cookies. If the
container is giving the client a session and the client has cookies enabled,
the container will return to the client a cookie that contains the session
id, and the client borwser submits this with its requests allowing the
container to identify which session the request belongs to. This mechanism
works almost transparently both to the user and the developer.

The second way - url rewriting - operates when cookies are disabled on the
client (and it is considered best practise to allow for this possibility as
a lot of users are getting paranoid about cookies these days). This involves
all links that are displayed in the browser including the session id as part
of the url - so you will see urls of the form:
http://www.mystery-machine.com/shaggy/scooby.do;jsessionid=4878D95252DE47FDC
39E69070F49F397

Obviously for the links to contain the session id the developer has to do a
bit more work - basically requiring all links to pages/actions participating
in that session to be 'rewritten'. The struts  tag will do this
for any links you render with it automatically, - I presume the 
tag will also do it for its action (I dont use jsp so arent entirely sure
but it would seem logical).

If you need to do it yourself somewhere the servlet apis HttpServletResponse
also supplies an encodeUrl() method that when passed a string containing a
plain url will add the session id if necessary and return the encoded url
string to you.


-Original Message-
From: Heligon Sandra [mailto:[EMAIL PROTECTED]
Sent: Thursday, 6 March 2003 16:41
To: 'Struts Users Mailing List'
Subject: RE: Association between Session object and Cookies/URL
rewriting
Importance: High


Tomcat is responsible of the cookie creation but it is
the Struts Action Servlet that is responsible of the
session (HttpSession initialization) isn't it ?
A few months ago I had had a discussion with Craig and it had indicated
to me that a session was initialized in several cases:

* The controller servlet will create a session for you, if you
  declare that your form bean is in session scope.

* The controller servlet will create a session for you, if you
  configured the automatic locale recognition mechanism (the "locale"
  servlet initialization parameter for 1.0, or the corresponding
  attribute on the  element for 1.1).

* Your application Action can create a session if it needs to, by
  calling request.getSession().

* Actions will create a session for you automatically if you use
  transaction tokens, or the getLocale()/setLocale() methods.

* JSP pages will create a session for you automatically unless you
  explicitly tell them not to (<%@ page ... session="false" ... %>).

* The  tag will create a session for you automatically
  if you use locale="true".

* The  tag will create a session for you automatically
  if your form bean is in request scope, or if you are using
  transaction tokens.

I don't understand how the controller distinguish a client X from a
client Y ? what parameter/information allow to identify a client ?
As I said yesterday in my application two clients have not the same
authentication information (userLogin and password).

If a client X enter th

RE: Association between Session object and Cookies/URL rewriting

[Andrew Hill]

HttpSession is a seperate matter from authentication as far as the container
is concerned, in as much as session tracking operates to associate requests
with a particular client. The way it does this is by allocated a session
id - which the client submits with each request.

There are two ways that this id can be submitted.
The first (and I believe the default) is to make use of cookies. If the
container is giving the client a session and the client has cookies enabled,
the container will return to the client a cookie that contains the session
id, and the client borwser submits this with its requests allowing the
container to identify which session the request belongs to. This mechanism
works almost transparently both to the user and the developer.

The second way - url rewriting - operates when cookies are disabled on the
client (and it is considered best practise to allow for this possibility as
a lot of users are getting paranoid about cookies these days). This involves
all links that are displayed in the browser including the session id as part
of the url - so you will see urls of the form:
http://www.mystery-machine.com/shaggy/scooby.do;jsessionid=4878D95252DE47FDC
39E69070F49F397

Obviously for the links to contain the session id the developer has to do a
bit more work - basically requiring all links to pages/actions participating
in that session to be 'rewritten'. The struts  tag will do this
for any links you render with it automatically, - I presume the 
tag will also do it for its action (I dont use jsp so arent entirely sure
but it would seem logical).

If you need to do it yourself somewhere the servlet apis HttpServletResponse
also supplies an encodeUrl() method that when passed a string containing a
plain url will add the session id if necessary and return the encoded url
string to you.


-Original Message-
From: Heligon Sandra [mailto:[EMAIL PROTECTED]
Sent: Thursday, 6 March 2003 16:41
To: 'Struts Users Mailing List'
Subject: RE: Association between Session object and Cookies/URL
rewriting
Importance: High


Tomcat is responsible of the cookie creation but it is
the Struts Action Servlet that is responsible of the
session (HttpSession initialization) isn't it ?
A few months ago I had had a discussion with Craig and it had indicated
to me that a session was initialized in several cases:

* The controller servlet will create a session for you, if you
  declare that your form bean is in session scope.

* The controller servlet will create a session for you, if you
  configured the automatic locale recognition mechanism (the "locale"
  servlet initialization parameter for 1.0, or the corresponding
  attribute on the  element for 1.1).

* Your application Action can create a session if it needs to, by
  calling request.getSession().

* Actions will create a session for you automatically if you use
  transaction tokens, or the getLocale()/setLocale() methods.

* JSP pages will create a session for you automatically unless you
  explicitly tell them not to (<%@ page ... session="false" ... %>).

* The  tag will create a session for you automatically
  if you use locale="true".

* The  tag will create a session for you automatically
  if your form bean is in request scope, or if you are using
  transaction tokens.

I don't understand how the controller distinguish a client X from a
client Y ? what parameter/information allow to identify a client ?
As I said yesterday in my application two clients have not the same
authentication information (userLogin and password).

If a client X enter the URL http::\\localhost:8080\MyAppli, when the
home page is displayed if the form is in the session an HttpSession is
created isn't it ? but the client has not yet given his userLogin and
password.

If a new browser is open on the same PC with the URL of the application
is a new HttpSession is created ?
Normally a new session must be created only if login information is
different
from the first client's browser. But on the Home page we do not have to
carry out
the Login action yet.

Do you understand my question ?

---
As of February 12, 2003 Thomson unifies its email addresses on a worldwide
basis.Please note my new email address: [EMAIL PROTECTED]

Thomson is the leader in solutions and technologies for the entertainment
and media industries and serves its customers under its four strategic
brands: Technicolor, Grass Valley, RCA and THOMSON.
More about Thomson: http://www.thomson.net/videochain

Original Message-
From: Nicolas De Loof [mailto:[EMAIL PROTECTED]
Sent: 05 March 2003 14:53
To: Struts Users Mailing List
Subject: Re: Association between Session object and Cookies/URL
rewriting


Struts doesn't create coockies, J2EE servlet container does (tomcat).
When you use "request.getSession()" in your code, J2EE server will a
coockie (or a request p

RE: Association between Session object and Cookies/URL rewriting

[Mohan Radhakrishnan]

Hi,
  Exactly what happens with my pet project here. The login page times
out before the user logs in  after the specified timeout period. I have been
pulling my hair all day.

 Need more explanation. I am using setLocale in the base action which my
login action is extending. I do understand the question.
Mohan
 
If a client X enter the URL http::\\localhost:8080\MyAppli, when the 
home page is displayed if the form is in the session an HttpSession is
created isn't it ? but the client has not yet given his userLogin and
password.

If a new browser is open on the same PC with the URL of the application
is a new HttpSession is created ?
Normally a new session must be created only if login information is
different
from the first client's browser. But on the Home page we do not have to
carry out 
the Login action yet.  

Do you understand my question ?

--- 
As of February 12, 2003 Thomson unifies its email addresses on a worldwide
basis.Please note my new email address: [EMAIL PROTECTED] 

Thomson is the leader in solutions and technologies for the entertainment
and media industries and serves its customers under its four strategic
brands: Technicolor, Grass Valley, RCA and THOMSON. 
More about Thomson: http://www.thomson.net/videochain 

Original Message-
From: Nicolas De Loof [mailto:[EMAIL PROTECTED]
Sent: 05 March 2003 14:53
To: Struts Users Mailing List
Subject: Re: Association between Session object and Cookies/URL
rewriting


Struts doesn't create coockies, J2EE servlet container does (tomcat).
When you use "request.getSession()" in your code, J2EE server will a
coockie (or a request parameter if URL rewriting is used, see your
server config) to get the session ID.

If no ID is set, it will generate a new session ID and add a
"set-coockie" HTTP header in response.

New request from user browser will come to the server with a
"SESSIONID" coockie header, and request.getSession() implementation
will be able to find the session object from ID.

Read J2EE or Tomcat documentation to get more infos on sessions
(sessionid coockie, URL rewriting ...).

Nico.

>
> I don't understand very well how Struts manages session objects
> and why a sessionID is fixed for a user ?
> Session objects are stored on the web server (Tomcat in my case) and
> cookie saved on the disk allows to retrieve the HttpSession
> associated to
> a user.
> But I don't understand how the cookie is created and why is it
> associated
> to a client ?
> How Struts creates the session cookie ?
> I read that the cookie object is created when a user first loads a
> web page that
> is a part of the application.
> But at this stage what distinguishes a user X from a user Y ?
> In my application I distinguish two users with authentication
> information but when the first page is displayed the authentication
is not
> done.
> How Struts know that it is a new user and that it has to create a
> new HtppSession and a new cookie?
> Is a user (and so a cookie) associated to a user NT account ?
> I am not certain to have been rather clear
> Thanks in advance for your help.
> Sandra
>
>
>
>
> ---
> As of February 12, 2003 Thomson unifies its email addresses on a
worldwide
> basis.Please note my new email address: [EMAIL PROTECTED]
>
> Thomson is the leader in solutions and technologies for the
entertainment
> and media industries and serves its customers under its four
strategic
> brands: Technicolor, Grass Valley, RCA and THOMSON.
> More about Thomson: http://www.thomson.net/videochain
>
>
> 
-
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Association between Session object and Cookies/URL rewriting

[Heligon Sandra]

Tomcat is responsible of the cookie creation but it is
the Struts Action Servlet that is responsible of the
session (HttpSession initialization) isn't it ?
A few months ago I had had a discussion with Craig and it had indicated 
to me that a session was initialized in several cases:

* The controller servlet will create a session for you, if you
  declare that your form bean is in session scope.

* The controller servlet will create a session for you, if you
  configured the automatic locale recognition mechanism (the "locale"
  servlet initialization parameter for 1.0, or the corresponding
  attribute on the  element for 1.1).

* Your application Action can create a session if it needs to, by
  calling request.getSession().

* Actions will create a session for you automatically if you use
  transaction tokens, or the getLocale()/setLocale() methods.

* JSP pages will create a session for you automatically unless you
  explicitly tell them not to (<%@ page ... session="false" ... %>).

* The  tag will create a session for you automatically
  if you use locale="true".

* The  tag will create a session for you automatically
  if your form bean is in request scope, or if you are using
  transaction tokens.

I don't understand how the controller distinguish a client X from a 
client Y ? what parameter/information allow to identify a client ?
As I said yesterday in my application two clients have not the same
authentication information (userLogin and password).
 
If a client X enter the URL http::\\localhost:8080\MyAppli, when the 
home page is displayed if the form is in the session an HttpSession is
created isn't it ? but the client has not yet given his userLogin and
password.

If a new browser is open on the same PC with the URL of the application
is a new HttpSession is created ?
Normally a new session must be created only if login information is
different
from the first client's browser. But on the Home page we do not have to
carry out 
the Login action yet.  

Do you understand my question ?

--- 
As of February 12, 2003 Thomson unifies its email addresses on a worldwide
basis.Please note my new email address: [EMAIL PROTECTED] 

Thomson is the leader in solutions and technologies for the entertainment
and media industries and serves its customers under its four strategic
brands: Technicolor, Grass Valley, RCA and THOMSON. 
More about Thomson: http://www.thomson.net/videochain 

Original Message-
From: Nicolas De Loof [mailto:[EMAIL PROTECTED]
Sent: 05 March 2003 14:53
To: Struts Users Mailing List
Subject: Re: Association between Session object and Cookies/URL
rewriting


Struts doesn't create coockies, J2EE servlet container does (tomcat).
When you use "request.getSession()" in your code, J2EE server will a
coockie (or a request parameter if URL rewriting is used, see your
server config) to get the session ID.

If no ID is set, it will generate a new session ID and add a
"set-coockie" HTTP header in response.

New request from user browser will come to the server with a
"SESSIONID" coockie header, and request.getSession() implementation
will be able to find the session object from ID.

Read J2EE or Tomcat documentation to get more infos on sessions
(sessionid coockie, URL rewriting ...).

Nico.

>
> I don't understand very well how Struts manages session objects
> and why a sessionID is fixed for a user ?
> Session objects are stored on the web server (Tomcat in my case) and
> cookie saved on the disk allows to retrieve the HttpSession
> associated to
> a user.
> But I don't understand how the cookie is created and why is it
> associated
> to a client ?
> How Struts creates the session cookie ?
> I read that the cookie object is created when a user first loads a
> web page that
> is a part of the application.
> But at this stage what distinguishes a user X from a user Y ?
> In my application I distinguish two users with authentication
> information but when the first page is displayed the authentication
is not
> done.
> How Struts know that it is a new user and that it has to create a
> new HtppSession and a new cookie?
> Is a user (and so a cookie) associated to a user NT account ?
> I am not certain to have been rather clear
> Thanks in advance for your help.
> Sandra
>
>
>
>
> ---
> As of February 12, 2003 Thomson unifies its email addresses on a
worldwide
> basis.Please note my new email address: [EMAIL PROTECTED]
>
> Thomson is the leader in solutions and technologies for the
entertainment
> and media industries and serves its customers under its four
strategic
> brands: Technicolor, Grass Valley, RCA and THOMSON.
> More about Thomso

Re: Association between Session object and Cookies/URL rewriting

[Nicolas De Loof]

Struts doesn't create coockies, J2EE servlet container does (tomcat).
When you use "request.getSession()" in your code, J2EE server will a
coockie (or a request parameter if URL rewriting is used, see your
server config) to get the session ID.

If no ID is set, it will generate a new session ID and add a
"set-coockie" HTTP header in response.

New request from user browser will come to the server with a
"SESSIONID" coockie header, and request.getSession() implementation
will be able to find the session object from ID.

Read J2EE or Tomcat documentation to get more infos on sessions
(sessionid coockie, URL rewriting ...).

Nico.

>
> I don't understand very well how Struts manages session objects
> and why a sessionID is fixed for a user ?
> Session objects are stored on the web server (Tomcat in my case) and
> cookie saved on the disk allows to retrieve the HttpSession
> associated to
> a user.
> But I don't understand how the cookie is created and why is it
> associated
> to a client ?
> How Struts creates the session cookie ?
> I read that the cookie object is created when a user first loads a
> web page that
> is a part of the application.
> But at this stage what distinguishes a user X from a user Y ?
> In my application I distinguish two users with authentication
> information but when the first page is displayed the authentication
is not
> done.
> How Struts know that it is a new user and that it has to create a
> new HtppSession and a new cookie?
> Is a user (and so a cookie) associated to a user NT account ?
> I am not certain to have been rather clear
> Thanks in advance for your help.
> Sandra
>
>
>
>
> ---
> As of February 12, 2003 Thomson unifies its email addresses on a
worldwide
> basis.Please note my new email address: [EMAIL PROTECTED]
>
> Thomson is the leader in solutions and technologies for the
entertainment
> and media industries and serves its customers under its four
strategic
> brands: Technicolor, Grass Valley, RCA and THOMSON.
> More about Thomson: http://www.thomson.net/videochain
>
>
> 
-
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Association between Session object and Cookies/URL rewriting

[Heligon Sandra]

I don't understand very well how Struts manages session objects
and why a sessionID is fixed for a user ?
Session objects are stored on the web server (Tomcat in my case) and
cookie saved on the disk allows to retrieve the HttpSession
associated to 
a user.
But I don't understand how the cookie is created and why is it
associated
to a client ?
How Struts creates the session cookie ?
I read that the cookie object is created when a user first loads a
web page that 
is a part of the application. 
But at this stage what distinguishes a user X from a user Y ? 
In my application I distinguish two users with authentication
information but when the first page is displayed the authentication is not
done. 
How Struts know that it is a new user and that it has to create a
new HtppSession and a new cookie?
Is a user (and so a cookie) associated to a user NT account ?
I am not certain to have been rather clear 
Thanks in advance for your help.
Sandra




--- 
As of February 12, 2003 Thomson unifies its email addresses on a worldwide
basis.Please note my new email address: [EMAIL PROTECTED] 

Thomson is the leader in solutions and technologies for the entertainment
and media industries and serves its customers under its four strategic
brands: Technicolor, Grass Valley, RCA and THOMSON. 
More about Thomson: http://www.thomson.net/videochain 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: without URL rewriting

[Joe Barefoot]

That's the only way I know ofyou could also copy the source from the LinkTag, make 
a new tag from it, and alter the new tag source to support a "urlRewrite" true/false 
attribute, but that's a lot more effort.


--joe

> -Original Message-
> From: Mark Chaimungkalanont [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 04, 2003 6:23 PM
> To: [EMAIL PROTECTED]
> Subject:  without URL rewriting
> 
> 
> I want to render an  or  tag without the URL
> rewriting.
> 
> Is it possible to optionally turn off URL rewriting?
> 
> Basically, we want to open a new session when we open a new 
> window, and the
> only way we found was to turn off cookies and use URL 
> rewriting to maintain
> sessions. We could then force a new session without 
> terminating the current
> one by opening up a page without the jsessionid appended. We 
> could hardcode
> the link but wanted to know whether I would be possible using 
> the anything
> from the Struts tag-libs.
> 
> Cheers
> 
> Mark C
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

without URL rewriting

[Mark Chaimungkalanont]

I want to render an  or  tag without the URL
rewriting.

Is it possible to optionally turn off URL rewriting?

Basically, we want to open a new session when we open a new window, and the
only way we found was to turn off cookies and use URL rewriting to maintain
sessions. We could then force a new session without terminating the current
one by opening up a page without the jsessionid appended. We could hardcode
the link but wanted to know whether I would be possible using the anything
from the Struts tag-libs.

Cheers

Mark C


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cookies vs. jsessionid (url rewriting)

[Craig R. McClanahan]

On Fri, 9 Aug 2002, Jung, Eric (Contractor) wrote:

> Date: Fri, 9 Aug 2002 07:14:20 -0700
> From: "Jung, Eric (Contractor)" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> Subject: RE: cookies vs. jsessionid (url rewriting)
>
> Sorry for begin vague. Still working on my first cup of coffee :)
> However, you can ignore my question because it seems to have magically
> gone away.
> As for your cookies point, well taken, and I know all the problems
> with cookies. However, it's simply not my call to make. If you've
> ever worked in a large corporate environment, you know there are many
> layers and groups trying to get along... and sometimes you can't call
> all the shots.

On the first request, Tomcat has no way to know whether cookies are
enabled or not, so it sends the session id both ways (in a cookie and with
encoded urls).  After that, if the session id comes back in as a cookie,
it stops rewriting.

If Tomcat is still rewriting URLs after the first request, that means it
didn't see the cookie, which means either your client didn't send it, or
there is some proxy or server in between that swallowed it.


>
> Using:
>   Stuts nightly build from 8 Aug 2002
>   Tomcat 4.0.4
>   JDK 1.3.something.or.other
>
> The first page looks like this. It's a JSP page:
>
>   HttpSession theSession = request.getSession(true);
>   Cookie cookie = new Cookie ("WorkbenchStyleId", "MELLON");
>   cookie.setMaxAge(365 * 24 * 60 * 60);
>   response.addCookie(cookie);
>
>   
> 
>   
>
> Yes, I know the cookie code shouldn't go in a JSP. I didn't write the code
> and don't have control over this part of it, so please don't beat me up!
> It's everything _after_ this point that I have control over.
>

Once you've done a , which does a RequestDispatcher.include()
thing underneath, the response has been committed and no further headers
can be set.  This is an HTTP restriction; not anything Struts can do
anything about.  You're going to have to rearrange your logic to make sure
that the session is created first.

Craig


> mainmenu.jsp looks like this
>
>
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
> <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
> <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
> <%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %>
>
>  scope="application">
>   
> ERROR:  Application resources not loaded -- check servlet container
> logs for error messages.
>   
> 
>
> 
>
>cellpadding="0">
> 
> 
>enctype="multipart/form-data">
>  
> 
>   
>   Click Browse and select a holdings data file in Excel format.
>   
> 
> 
>   
>   
>   
> 
> 
>   
>   Send File
>   
> 
>   
>    
> 
> 
>   
>
> -Original Message-
> From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 09, 2002 9:59 AM
> To: Struts Users Mailing List
> Subject: Re: cookies vs. jsessionid (url rewriting)
>
>
> Maybe you'd care to elaborate a bit on what server you're using -
> version and such.  Knowing which version of Struts you're using would be
> helpful too.  Also, I assume you're using the html:link tag, but you
> didn't say that.  Maybe you could restate your question a bit more
> completely?  Are you 110% sure that you don't have cookies disabled?
>
> Regards,
>
> Eddie
>
> (Oh, and, you realize that there are a myriad of over-paranoid folks out
> there that are going to turn off JavaScript and cookies, right?  If
> cookies are disabled, URL rewriting is a good thing.)
>
> Jung, Eric (Contractor) wrote:
>
> >Hi,
> >The first page in my application creates a session and writes a cookie on
> >the user's machine. However, when subsequent pages are hit, Struts uses a
> >jsessionid parameter in the URL. What gives? My requirements dictate I must
> >use this cookie, not URL rewriting.
> >
> >Thanks,
> >Eric Jung
> >
> >--
> >To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: cookies vs. jsessionid (url rewriting)

[Jung, Eric (Contractor)]

Problem resolved! (don't ask my how or why)
Thanks anyway.
-Eric

-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 09, 2002 10:27 AM
To: Struts Users Mailing List
Subject: Re: cookies vs. jsessionid (url rewriting)


Jung, Eric (Contractor) wrote:

>Sorry for begin vague. Still working on my first cup of coffee :)
>However, you can ignore my question because it seems to have magically
>gone away.
>As for your cookies point, well taken, and I know all the problems
>with cookies. However, it's simply not my call to make. If you've
>ever worked in a large corporate environment, you know there are many
>layers and groups trying to get along... and sometimes you can't call
>all the shots.
>
Yes, unfortunately, I have :-/  Point well taken.

>Using:
>  Stuts nightly build from 8 Aug 2002
>  Tomcat 4.0.4
>  JDK 1.3.something.or.other
>
>The first page looks like this. It's a JSP page:
>
>  HttpSession theSession = request.getSession(true);
>  Cookie cookie = new Cookie ("WorkbenchStyleId", "MELLON");
>  cookie.setMaxAge(365 * 24 * 60 * 60);
>  response.addCookie(cookie);
>  
>  
>
>  
>
>Yes, I know the cookie code shouldn't go in a JSP. I didn't write the code
>and don't have control over this part of it, so please don't beat me up!
>It's everything _after_ this point that I have control over.
>
LOL, I don't think we're here to bash folks ;-)  I'm a bit cheerier now 
too (on CoC #2 / CoC = Cup of Coffee ;-)

Ok, now, being under my 3 CoC standard (which is where my brain really 
starts the synapses firing good), I'm confuzzled.  You got it working 
and posted your code for us to pick apart anyway?  Are you under your 
CoC standard?!  LOL :-)  If you got your problem resolved; good.  If not 
just let us know what your problem is ;-)

Regards,

Eddie



--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: cookies vs. jsessionid (url rewriting)

[Eddie Bush]

Jung, Eric (Contractor) wrote:

>Sorry for begin vague. Still working on my first cup of coffee :)
>However, you can ignore my question because it seems to have magically
>gone away.
>As for your cookies point, well taken, and I know all the problems
>with cookies. However, it's simply not my call to make. If you've
>ever worked in a large corporate environment, you know there are many
>layers and groups trying to get along... and sometimes you can't call
>all the shots.
>
Yes, unfortunately, I have :-/  Point well taken.

>Using:
>  Stuts nightly build from 8 Aug 2002
>  Tomcat 4.0.4
>  JDK 1.3.something.or.other
>
>The first page looks like this. It's a JSP page:
>
>  HttpSession theSession = request.getSession(true);
>  Cookie cookie = new Cookie ("WorkbenchStyleId", "MELLON");
>  cookie.setMaxAge(365 * 24 * 60 * 60);
>  response.addCookie(cookie);
>  
>  
>
>  
>
>Yes, I know the cookie code shouldn't go in a JSP. I didn't write the code
>and don't have control over this part of it, so please don't beat me up!
>It's everything _after_ this point that I have control over.
>
LOL, I don't think we're here to bash folks ;-)  I'm a bit cheerier now 
too (on CoC #2 / CoC = Cup of Coffee ;-)

Ok, now, being under my 3 CoC standard (which is where my brain really 
starts the synapses firing good), I'm confuzzled.  You got it working 
and posted your code for us to pick apart anyway?  Are you under your 
CoC standard?!  LOL :-)  If you got your problem resolved; good.  If not 
just let us know what your problem is ;-)

Regards,

Eddie



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cookies vs. jsessionid (url rewriting)

[Jung, Eric (Contractor)]

Sorry for begin vague. Still working on my first cup of coffee :)
However, you can ignore my question because it seems to have magically
gone away.
As for your cookies point, well taken, and I know all the problems
with cookies. However, it's simply not my call to make. If you've
ever worked in a large corporate environment, you know there are many
layers and groups trying to get along... and sometimes you can't call
all the shots.

Using:
  Stuts nightly build from 8 Aug 2002
  Tomcat 4.0.4
  JDK 1.3.something.or.other

The first page looks like this. It's a JSP page:

  HttpSession theSession = request.getSession(true);
  Cookie cookie = new Cookie ("WorkbenchStyleId", "MELLON");
  cookie.setMaxAge(365 * 24 * 60 * 60);
  response.addCookie(cookie);
  
  

  

Yes, I know the cookie code shouldn't go in a JSP. I didn't write the code
and don't have control over this part of it, so please don't beat me up!
It's everything _after_ this point that I have control over.

mainmenu.jsp looks like this


<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
<%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %>


  
ERROR:  Application resources not loaded -- check servlet container
logs for error messages.
  




  


  
 

  
  Click Browse and select a holdings data file in Excel format.
  


  
  
  


  
  Send File
  

  
       

    
  

-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 09, 2002 9:59 AM
To: Struts Users Mailing List
Subject: Re: cookies vs. jsessionid (url rewriting)


Maybe you'd care to elaborate a bit on what server you're using - 
version and such.  Knowing which version of Struts you're using would be 
helpful too.  Also, I assume you're using the html:link tag, but you 
didn't say that.  Maybe you could restate your question a bit more 
completely?  Are you 110% sure that you don't have cookies disabled?

Regards,

Eddie

(Oh, and, you realize that there are a myriad of over-paranoid folks out 
there that are going to turn off JavaScript and cookies, right?  If 
cookies are disabled, URL rewriting is a good thing.)

Jung, Eric (Contractor) wrote:

>Hi,
>The first page in my application creates a session and writes a cookie on
>the user's machine. However, when subsequent pages are hit, Struts uses a
>jsessionid parameter in the URL. What gives? My requirements dictate I must
>use this cookie, not URL rewriting.
>
>Thanks,
>Eric Jung
>
>--
>To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>



--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: cookies vs. jsessionid (url rewriting)

[Eddie Bush]

Maybe you'd care to elaborate a bit on what server you're using - 
version and such.  Knowing which version of Struts you're using would be 
helpful too.  Also, I assume you're using the html:link tag, but you 
didn't say that.  Maybe you could restate your question a bit more 
completely?  Are you 110% sure that you don't have cookies disabled?

Regards,

Eddie

(Oh, and, you realize that there are a myriad of over-paranoid folks out 
there that are going to turn off JavaScript and cookies, right?  If 
cookies are disabled, URL rewriting is a good thing.)

Jung, Eric (Contractor) wrote:

>Hi,
>The first page in my application creates a session and writes a cookie on
>the user's machine. However, when subsequent pages are hit, Struts uses a
>jsessionid parameter in the URL. What gives? My requirements dictate I must
>use this cookie, not URL rewriting.
>
>Thanks,
>Eric Jung
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

cookies vs. jsessionid (url rewriting)

[Jung, Eric (Contractor)]

Hi,
The first page in my application creates a session and writes a cookie on
the user's machine. However, when subsequent pages are hit, Struts uses a
jsessionid parameter in the URL. What gives? My requirements dictate I must
use this cookie, not URL rewriting.

Thanks,
Eric Jung

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: URL Rewriting support in Struts and

[Craig R. McClanahan]

On Fri, 2 Aug 2002, Nekkalapudi, Viplava wrote:

> Date: Fri, 2 Aug 2002 14:47:29 -0500
> From: "Nekkalapudi, Viplava" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: URL Rewriting support in Struts  and 
>
> 
>  All containers that implement Servlet 2.2 or 2.3 are required to support
> "URL rewriting", which encodes the session identifier in the url as a path
> parameter (not a query parameter). However, it is up to your application to
> make sure you call response.encodeURL() as you are creating such links. The
> good news for Struts users is that tags like  and  do
> this for you, so that if you create all your links with the tags, you don't
> have to worry about URL rewriting yourself.
> 
>
>  This means if I disable Cookies in  my browser (either by disabling from
> browser settings or through weblogic.xml with ,
>  our web application developed with Struts 1.0.2 and Weblogic Server 6.1
> should work fine.
>  But it is not working if we disable cookies.
>

If you always construct your hyperlinks using , then this
should indeed work.  It sounds like there might be a problem with URL
rewriting in WebLogic.

A quick way to check this would be to put something like this in your
page:

  Test Link

and examine the HTML output that gets created.  You should see a URL that
has a ";JSESSIONID=" path parameter if cookies are turned off.  Because
this bypasses the Struts tag, it can directly prove whether there is a
problem with your container or not.

>  Please clarify.
> ---  Vip

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

URL Rewriting support in Struts and

[Nekkalapudi, Viplava]

 All containers that implement Servlet 2.2 or 2.3 are required to support
"URL rewriting", which encodes the session identifier in the url as a path
parameter (not a query parameter). However, it is up to your application to
make sure you call response.encodeURL() as you are creating such links. The
good news for Struts users is that tags like  and  do
this for you, so that if you create all your links with the tags, you don't
have to worry about URL rewriting yourself. 


 This means if I disable Cookies in  my browser (either by disabling from
browser settings or through weblogic.xml with , 
 our web application developed with Struts 1.0.2 and Weblogic Server 6.1
should work fine.
 But it is not working if we disable cookies. 

 Please clarify.
---  Vip

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: RE: SSL + URL rewriting problem

[Nathan Anderson]

The problem is not that it is "speaking" on port 443, but that it is using http not 
https.  

This is what I think is happening...
1. A request is sent from the client to "https://hostname/appname/index.jsp";
2. Apache 1.3.22 recieves this request and verifies the users certificate and keys.
3. Apache querys the modWebApp if it should pass this requst to the warp connector.
4. A _NEW_ unencrypted [http] request is generated by Apache [or the warp connector] 
and sent to the servlet container [Tomcat 4.0.1]
5. The request generated by Apache is not encrypted, so when "request.getRequestURL()" 
is called, it responds as "http", and it adds the port because 443 is not the default 
http port.  So the resulting URL is "http://hostname:443/appname/index.jsp";.

The only work around I have found is to only use relative paths in my application 
[i.e. no html:base or html:image tags]

Nathan Anderson
--
Sent via jApache.org

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: SSL + URL rewriting problem

[Max Cooper]

Mark,

Please tell Netscape's cookie subsystem! I know they are essentially the
same, but Netscape doesn't view them that way and won't send cookies set by
https://hostname to https://hostname:443 so it does turn out to be a problem
anyway. It would be ideal if the web/app server would not mess with the URL
as long as you don't need to switch ports.

-Max

- Original Message -
From: "Galbreath, Mark" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Friday, February 08, 2002 3:45 AM
Subject: RE: SSL + URL rewriting problem


> Port 443 is the default Secure Sockets Layer port, so it is going to the
URL
> you passed.
>
> Mark
>
> -Original Message-
> From: Nathan Anderson [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 07, 2002 7:00 PM
> To: [EMAIL PROTECTED]
> Subject: Re: SSL + URL rewriting problem
>
>
> I have a bit more information if anyone is interested in helping me with
> this issue..
>
> I found out that the HttpUtils.getRequestURL().  If I make a JSP with the
> following scriptlet:
>
> <%= HttpUtils.getRequestURL(request) %>
>
> I get this:
>
> http://hostname:443/webapp/page.jsp
>
> when the actual request URL was:
>
> https://hostname/webapp/page.jsp
>
> Any ideas appreciated.
>
> Nathan Anderson
> --
> Sent via jApache.org
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: SSL + URL rewriting problem

[Galbreath, Mark]

Port 443 is the default Secure Sockets Layer port, so it is going to the URL
you passed.

Mark

-Original Message-
From: Nathan Anderson [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 07, 2002 7:00 PM
To: [EMAIL PROTECTED]
Subject: Re: SSL + URL rewriting problem


I have a bit more information if anyone is interested in helping me with
this issue..

I found out that the HttpUtils.getRequestURL().  If I make a JSP with the
following scriptlet:

<%= HttpUtils.getRequestURL(request) %>

I get this:

http://hostname:443/webapp/page.jsp

when the actual request URL was:

https://hostname/webapp/page.jsp

Any ideas appreciated.

Nathan Anderson
--
Sent via jApache.org

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: SSL + URL rewriting problem

[Nathan Anderson]

Thanks for the info.  

You are correct that I was referring to javax.servlet.http.HttpUtils.  So I tried it 
using the object [request.getRequestURL], and I got the exact same thing.  

I guess this is not a "Struts" issue, so I'll keep looking.

Nathan Anderson
--
Sent via jApache.org

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: SSL + URL rewriting problem

[Max Cooper]

Nathan,

I have noticed the behavior you describe on a Struts application that I
worked on. However, I was not sure of why the :443 was added until your
post. I was thinking that it was the web server, perhaps not.

Anyway, one issue to watch out for is that Netscape considers these two URLs
to be from different servers, and thus won't send the session cookie from
one to the other:

> https://hostname:443/webapp/page.jsp
> https://hostname/webapp/page.jsp

If you are having trouble with people getting redirected back to your login
page after they login with Netscape, this issue might be the cause. One
solution (that has the significant downside that you have to maintain the
setting) is to set the cookie domain for your server. You usually set it to
the fully qualified domain name of your web server. The details of how to do
that depend on what app server you are using.

-Max

- Original Message -
From: "Nathan Anderson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 07, 2002 3:59 PM
Subject: Re: SSL + URL rewriting problem


> I have a bit more information if anyone is interested in helping me with
this issue..
>
> I found out that the HttpUtils.getRequestURL().  If I make a JSP with the
following scriptlet:
>
> <%= HttpUtils.getRequestURL(request) %>
>
> I get this:
>
> http://hostname:443/webapp/page.jsp
>
> when the actual request URL was:
>
> https://hostname/webapp/page.jsp
>
> Any ideas appreciated.
>
> Nathan Anderson
> --
> Sent via jApache.org
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: SSL + URL rewriting problem

[Dan Moore]

Hi Nathan,

On Feb 7, Nathan Anderson wrote:

> I have a bit more information if anyone is interested in helping me with this issue..
> 
> I found out that the HttpUtils.getRequestURL().  If I make a JSP with the following 
>scriptlet:

I assume you're talking about javax.servlet.http.HttpUtils here (I just
joined the list and it's not clear.)  If you aren't, please ignore the rest
of this message (because it's predicated on you using this class).

Note, based on:
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpUtils.html
this is deprecated in favor of the request objects.


> <%= HttpUtils.getRequestURL(request) %>
> 
> I get this:
> 
> http://hostname:443/webapp/page.jsp
> 
> when the actual request URL was:
> 
> https://hostname/webapp/page.jsp
> 
> Any ideas appreciated.
 
So, looking at the HttpServletRequest
(http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpServletRequest.html),
 I see these methods:

getProtocol which "Returns the name and version of the protocol the request
uses in the form protocol/majorVersion.minorVersion, for example, HTTP/1.1.
For HTTP servlets, the value returned is the same as the value of the CGI
variable SERVER_PROTOCOL."

This method is also present in the 2.2 Servlet api as well.

Hope this helps.

Dan



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: SSL + URL rewriting problem

[Nathan Anderson]

I have a bit more information if anyone is interested in helping me with this issue..

I found out that the HttpUtils.getRequestURL().  If I make a JSP with the following 
scriptlet:

<%= HttpUtils.getRequestURL(request) %>

I get this:

http://hostname:443/webapp/page.jsp

when the actual request URL was:

https://hostname/webapp/page.jsp

Any ideas appreciated.

Nathan Anderson
--
Sent via jApache.org

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

SSL + URL rewriting problem

[Nathan Anderson]

Hello all, 

I've been trying to get my Apache 1.3.22 + Tomcat 4.0.1 [via mod_WebApp] installation 
to work with SSL.  So far I've had some success, but there is one problem left that 
seems to only effect Struts applications.  

All my non-struts .JSP's and servlets work without any issues.  But in Struts, all of 
the URL's are being written like this:
http://www.hostname.com:443/strutsapp/...  

I'm probably missing something that will be fairly obvious to some of you but I just 
can't seem to figure it out.  Do any of you have suggestions, or links to help me out?

Nathan Anderson
--
Sent via jApache.org

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: URL Rewriting

[Jesse Alexander (KABS 11)]

Hi,

well the first phrase "I've read...code. <%... " gives exactly a working
code-snippet. I think using that it should be easy to get a working
version in your own code...

hope this helps
Alexander Jesse

PS: search for "HashMap link" gives you an even better hitlist, where you
can find other samples...

-Original Message-
From: João Guilherme Del Valle [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 19, 2001 1:55 PM
To: Struts Users Mailing List
Subject: Re: URL Rewriting


Ok, the message you said follows.
But, the "" tag doesn´t _still_ exist in struts, right? Is
there a standart way to pass more than one parameter?


>
> Thanks for all the help people, I can now successfully pass one
> variable.  How can I pass more that one variable?

Hi,

I've read this in the struts examples that come with the source code.
<%
   java.util.HashMap newValues = new java.util.HashMap();
   newValues.put("para1", "value1");
   newValues.put("para2", bean1.getAttribute1();
   pageContext.setAttribute("paras", newValues);
%>

   


You put all your parameters in a hashmap an pass it to the
 tag.

I would prefer something like this:

   
   


but this is still not in the stuts source, I guess.

Volker



Joao Guilherme Del Valle
[EMAIL PROTECTED]
Visionnaire Informática SA
http://www.visionnaire.com.br
Tel/Fax: +55 41 373-7400 r: 217


- Original Message -
From: "Jesse Alexander (KABS 11)" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Wednesday, December 19, 2001 8:41 AM
Subject: RE: URL Rewriting


> Hi,
>
> have you checked in the mailing-list-archives at:
>
> http://www.mail-archive.com/struts-user@jakarta.apache.org/
>
> Searching for "HashMap" resulted in a list containing a reference to
> this message:
>
> http://www.mail-archive.com/struts-user@jakarta.apache.org/msg19443.html
>
> Which seems to do what you want...
>
>
> hope this helps
> Alexander Jesse
>
> -Original Message-
> From: Sudhir S. Shetty [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 19, 2001 12:27 PM
> To: Struts Users Mailing List
> Subject: Re: URL Rewriting
>
>
> Can anybody please mail me the syntax for sending multiple (3-4)
parameters
> through the  tag , if possible with some code if using the Map
> inter face.
> thanks,
> Sudhir
> - Original Message -
> From: "Tom Klaasen (TeleRelay)" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Tuesday, December 18, 2001 18:23
> Subject: RE: URL Rewriting
>
>
> 
> 
> http://jakarta.apache.org/struts/struts-html.html#link
> 
> 
> If you prefer to specify a java.util.Map that contains all of the
> request parameters to be added to the hyperlink, use one of the
> following techniques:
>
>
> Specify only the name attribute - The named JSP bean (optionally scoped
> by the value of the scope attribute) must identify a java.util.Map
> containing the parameters.
> Specify both name and property attributes - The specified property
> getter method will be called on the bean identified by the name (and
> optional scope) attributes, in order to return the java.util.Map
> containing the parameters.
> As the Map is processed, the keys are assumed to be the names of query
> parameters to be appended to the hyperlink. The value associated with
> each key must be either a String or a String array representing the
> parameter value(s), or an object whose toString() method will be called.
> If a String array is specified, more than one value for the same query
> parameter name will be created.
> 
> 
>
> hth,
> tomK
>
>
>
> > -Original Message-
> > From: Sudhir S. Shetty [mailto:[EMAIL PROTECTED]]
> > Sent: dinsdag 18 december 2001 13:48
> > To: Struts Users Mailing List
> > Subject: URL Rewriting
> >
> >
> > Hi Everybody,
> >I've just started using struts in my
> > application, I
> > have a Overview Screen from which I have to pass 2 request
> > parameters to the
> > ActionForward bean, I dont have a Form Bean for this overview screen.
> > The problem I face is using URL rewiting, when i pass these
> > parametrs in the
> >  tag it gives me an error, and if i use the  tag I
> > bypass the servlet, Kindly suggest me a method, or the right
> > syntax for
> > .
> > The Link I've used in my app is as follows :-
> >  > page="fee.do?action=Edit&ls_company_name=<%=rs.getString(2)%>&
> > l

Re: URL Rewriting

[João Guilherme Del Valle]

Ok, the message you said follows.
But, the "" tag doesn´t _still_ exist in struts, right? Is
there a standart way to pass more than one parameter?


>
> Thanks for all the help people, I can now successfully pass one
> variable.  How can I pass more that one variable?

Hi,

I've read this in the struts examples that come with the source code.
<%
   java.util.HashMap newValues = new java.util.HashMap();
   newValues.put("para1", "value1");
   newValues.put("para2", bean1.getAttribute1();
   pageContext.setAttribute("paras", newValues);
%>

   


You put all your parameters in a hashmap an pass it to the
 tag.

I would prefer something like this:

   
   


but this is still not in the stuts source, I guess.

Volker



Joao Guilherme Del Valle
[EMAIL PROTECTED]
Visionnaire Informática SA
http://www.visionnaire.com.br
Tel/Fax: +55 41 373-7400 r: 217


- Original Message -
From: "Jesse Alexander (KABS 11)" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Wednesday, December 19, 2001 8:41 AM
Subject: RE: URL Rewriting


> Hi,
>
> have you checked in the mailing-list-archives at:
>
> http://www.mail-archive.com/struts-user@jakarta.apache.org/
>
> Searching for "HashMap" resulted in a list containing a reference to
> this message:
>
> http://www.mail-archive.com/struts-user@jakarta.apache.org/msg19443.html
>
> Which seems to do what you want...
>
>
> hope this helps
> Alexander Jesse
>
> -Original Message-
> From: Sudhir S. Shetty [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 19, 2001 12:27 PM
> To: Struts Users Mailing List
> Subject: Re: URL Rewriting
>
>
> Can anybody please mail me the syntax for sending multiple (3-4)
parameters
> through the  tag , if possible with some code if using the Map
> inter face.
> thanks,
> Sudhir
> - Original Message -
> From: "Tom Klaasen (TeleRelay)" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Tuesday, December 18, 2001 18:23
> Subject: RE: URL Rewriting
>
>
> 
> 
> http://jakarta.apache.org/struts/struts-html.html#link
> 
> 
> If you prefer to specify a java.util.Map that contains all of the
> request parameters to be added to the hyperlink, use one of the
> following techniques:
>
>
> Specify only the name attribute - The named JSP bean (optionally scoped
> by the value of the scope attribute) must identify a java.util.Map
> containing the parameters.
> Specify both name and property attributes - The specified property
> getter method will be called on the bean identified by the name (and
> optional scope) attributes, in order to return the java.util.Map
> containing the parameters.
> As the Map is processed, the keys are assumed to be the names of query
> parameters to be appended to the hyperlink. The value associated with
> each key must be either a String or a String array representing the
> parameter value(s), or an object whose toString() method will be called.
> If a String array is specified, more than one value for the same query
> parameter name will be created.
> 
> 
>
> hth,
> tomK
>
>
>
> > -Original Message-
> > From: Sudhir S. Shetty [mailto:[EMAIL PROTECTED]]
> > Sent: dinsdag 18 december 2001 13:48
> > To: Struts Users Mailing List
> > Subject: URL Rewriting
> >
> >
> > Hi Everybody,
> >I've just started using struts in my
> > application, I
> > have a Overview Screen from which I have to pass 2 request
> > parameters to the
> > ActionForward bean, I dont have a Form Bean for this overview screen.
> > The problem I face is using URL rewiting, when i pass these
> > parametrs in the
> >  tag it gives me an error, and if i use the  tag I
> > bypass the servlet, Kindly suggest me a method, or the right
> > syntax for
> > .
> > The Link I've used in my app is as follows :-
> >  > page="fee.do?action=Edit&ls_company_name=<%=rs.getString(2)%>&
> > ls_rate_table=
> > <%=rs.getString(3)%>"> <%=rs.getString(1)%>
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:struts-user-> [EMAIL PROTECTED]>
> > For
> > additional commands,
> > e-mail: <mailto:[EMAIL PROTECTED]>
> >
> >
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: URL Rewriting

[Jesse Alexander (KABS 11)]

Hi,

have you checked in the mailing-list-archives at:

http://www.mail-archive.com/struts-user@jakarta.apache.org/

Searching for "HashMap" resulted in a list containing a reference to
this message:

http://www.mail-archive.com/struts-user@jakarta.apache.org/msg19443.html

Which seems to do what you want...


hope this helps
Alexander Jesse

-Original Message-
From: Sudhir S. Shetty [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 19, 2001 12:27 PM
To: Struts Users Mailing List
Subject: Re: URL Rewriting


Can anybody please mail me the syntax for sending multiple (3-4) parameters
through the  tag , if possible with some code if using the Map
inter face.
thanks,
Sudhir
- Original Message -
From: "Tom Klaasen (TeleRelay)" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Tuesday, December 18, 2001 18:23
Subject: RE: URL Rewriting




http://jakarta.apache.org/struts/struts-html.html#link


If you prefer to specify a java.util.Map that contains all of the
request parameters to be added to the hyperlink, use one of the
following techniques:


Specify only the name attribute - The named JSP bean (optionally scoped
by the value of the scope attribute) must identify a java.util.Map
containing the parameters.
Specify both name and property attributes - The specified property
getter method will be called on the bean identified by the name (and
optional scope) attributes, in order to return the java.util.Map
containing the parameters.
As the Map is processed, the keys are assumed to be the names of query
parameters to be appended to the hyperlink. The value associated with
each key must be either a String or a String array representing the
parameter value(s), or an object whose toString() method will be called.
If a String array is specified, more than one value for the same query
parameter name will be created.



hth,
tomK



> -Original Message-
> From: Sudhir S. Shetty [mailto:[EMAIL PROTECTED]]
> Sent: dinsdag 18 december 2001 13:48
> To: Struts Users Mailing List
> Subject: URL Rewriting
>
>
> Hi Everybody,
>I've just started using struts in my
> application, I
> have a Overview Screen from which I have to pass 2 request
> parameters to the
> ActionForward bean, I dont have a Form Bean for this overview screen.
> The problem I face is using URL rewiting, when i pass these
> parametrs in the
>  tag it gives me an error, and if i use the  tag I
> bypass the servlet, Kindly suggest me a method, or the right
> syntax for
> .
> The Link I've used in my app is as follows :-
>  page="fee.do?action=Edit&ls_company_name=<%=rs.getString(2)%>&
> ls_rate_table=
> <%=rs.getString(3)%>"> <%=rs.getString(1)%>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-> [EMAIL PROTECTED]>
> For
> additional commands,
> e-mail: <mailto:[EMAIL PROTECTED]>
>
>

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: URL Rewriting

[Sudhir S. Shetty]

Can anybody please mail me the syntax for sending multiple (3-4) parameters
through the  tag , if possible with some code if using the Map
inter face.
thanks,
Sudhir
- Original Message -
From: "Tom Klaasen (TeleRelay)" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Tuesday, December 18, 2001 18:23
Subject: RE: URL Rewriting




http://jakarta.apache.org/struts/struts-html.html#link


If you prefer to specify a java.util.Map that contains all of the
request parameters to be added to the hyperlink, use one of the
following techniques:


Specify only the name attribute - The named JSP bean (optionally scoped
by the value of the scope attribute) must identify a java.util.Map
containing the parameters.
Specify both name and property attributes - The specified property
getter method will be called on the bean identified by the name (and
optional scope) attributes, in order to return the java.util.Map
containing the parameters.
As the Map is processed, the keys are assumed to be the names of query
parameters to be appended to the hyperlink. The value associated with
each key must be either a String or a String array representing the
parameter value(s), or an object whose toString() method will be called.
If a String array is specified, more than one value for the same query
parameter name will be created.



hth,
tomK



> -Original Message-
> From: Sudhir S. Shetty [mailto:[EMAIL PROTECTED]]
> Sent: dinsdag 18 december 2001 13:48
> To: Struts Users Mailing List
> Subject: URL Rewriting
>
>
> Hi Everybody,
>I've just started using struts in my
> application, I
> have a Overview Screen from which I have to pass 2 request
> parameters to the
> ActionForward bean, I dont have a Form Bean for this overview screen.
> The problem I face is using URL rewiting, when i pass these
> parametrs in the
>  tag it gives me an error, and if i use the  tag I
> bypass the servlet, Kindly suggest me a method, or the right
> syntax for
> .
> The Link I've used in my app is as follows :-
>  page="fee.do?action=Edit&ls_company_name=<%=rs.getString(2)%>&
> ls_rate_table=
> <%=rs.getString(3)%>"> <%=rs.getString(1)%>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-> [EMAIL PROTECTED]>
> For
> additional commands,
> e-mail: <mailto:[EMAIL PROTECTED]>
>
>

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: URL Rewriting

[Sudhir S. Shetty]

Can anyone give me some example code with reference to the following example
thanks ,
regards,
Sudhir
- Original Message -
From: "Tom Klaasen (TeleRelay)" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Tuesday, December 18, 2001 18:23
Subject: RE: URL Rewriting




http://jakarta.apache.org/struts/struts-html.html#link


If you prefer to specify a java.util.Map that contains all of the
request parameters to be added to the hyperlink, use one of the
following techniques:


Specify only the name attribute - The named JSP bean (optionally scoped
by the value of the scope attribute) must identify a java.util.Map
containing the parameters.
Specify both name and property attributes - The specified property
getter method will be called on the bean identified by the name (and
optional scope) attributes, in order to return the java.util.Map
containing the parameters.
As the Map is processed, the keys are assumed to be the names of query
parameters to be appended to the hyperlink. The value associated with
each key must be either a String or a String array representing the
parameter value(s), or an object whose toString() method will be called.
If a String array is specified, more than one value for the same query
parameter name will be created.



hth,
tomK



> -Original Message-
> From: Sudhir S. Shetty [mailto:[EMAIL PROTECTED]]
> Sent: dinsdag 18 december 2001 13:48
> To: Struts Users Mailing List
> Subject: URL Rewriting
>
>
> Hi Everybody,
>I've just started using struts in my
> application, I
> have a Overview Screen from which I have to pass 2 request
> parameters to the
> ActionForward bean, I dont have a Form Bean for this overview screen.
> The problem I face is using URL rewiting, when i pass these
> parametrs in the
>  tag it gives me an error, and if i use the  tag I
> bypass the servlet, Kindly suggest me a method, or the right
> syntax for
> .
> The Link I've used in my app is as follows :-
>  page="fee.do?action=Edit&ls_company_name=<%=rs.getString(2)%>&
> ls_rate_table=
> <%=rs.getString(3)%>"> <%=rs.getString(1)%>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-> [EMAIL PROTECTED]>
> For
> additional commands,
> e-mail: <mailto:[EMAIL PROTECTED]>
>
>

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: URL Rewriting

[Tom Klaasen (TeleRelay)]

http://jakarta.apache.org/struts/struts-html.html#link


If you prefer to specify a java.util.Map that contains all of the
request parameters to be added to the hyperlink, use one of the
following techniques:


Specify only the name attribute - The named JSP bean (optionally scoped
by the value of the scope attribute) must identify a java.util.Map
containing the parameters. 
Specify both name and property attributes - The specified property
getter method will be called on the bean identified by the name (and
optional scope) attributes, in order to return the java.util.Map
containing the parameters. 
As the Map is processed, the keys are assumed to be the names of query
parameters to be appended to the hyperlink. The value associated with
each key must be either a String or a String array representing the
parameter value(s), or an object whose toString() method will be called.
If a String array is specified, more than one value for the same query
parameter name will be created.



hth,
tomK



> -Original Message-
> From: Sudhir S. Shetty [mailto:[EMAIL PROTECTED]] 
> Sent: dinsdag 18 december 2001 13:48
> To: Struts Users Mailing List
> Subject: URL Rewriting
> 
> 
> Hi Everybody,
>I've just started using struts in my 
> application, I
> have a Overview Screen from which I have to pass 2 request 
> parameters to the
> ActionForward bean, I dont have a Form Bean for this overview screen.
> The problem I face is using URL rewiting, when i pass these 
> parametrs in the
>  tag it gives me an error, and if i use the  tag I
> bypass the servlet, Kindly suggest me a method, or the right 
> syntax for
> .
> The Link I've used in my app is as follows :-
>  page="fee.do?action=Edit&ls_company_name=<%=rs.getString(2)%>&
> ls_rate_table=
> <%=rs.getString(3)%>"> <%=rs.getString(1)%>
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:struts-user-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

URL Rewriting

[Sudhir S. Shetty]

Hi Everybody,
   I've just started using struts in my application, I
have a Overview Screen from which I have to pass 2 request parameters to the
ActionForward bean, I dont have a Form Bean for this overview screen.
The problem I face is using URL rewiting, when i pass these parametrs in the
 tag it gives me an error, and if i use the  tag I
bypass the servlet, Kindly suggest me a method, or the right syntax for
.
The Link I've used in my app is as follows :-
 <%=rs.getString(1)%>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: URL rewriting and cookies

[Ted Husted]

The img tag is mainly there in case the images in a secure location, and
the user needs to be logged in to get them. In which case, URL rewriting
would be required to retrieve them (or the user would be asked to log in
to retrieve each image ;-(

You are not required to use the img tag if the images are in a public
location. If the images are on another server, you may want to pass the
URL in a bean, or as part of your own tag. If not, you can also use the
conventional http://www.husted.com/struts/


Aapo Laakkonen wrote:
> 
> > The Struts tag is doing this because this is the
> > result of URL rewriting. The syntax is "strange",
> > as you put it, because the session id is encoded
> > as a path parameter, and not part of the query
> > string. This is all explained in the Servlet spec.
> 
> Is it possible to fix this behavior somehow? What
> do you mean about strange syntax? And I'm still not
> sure that where the problem exists. Are you saying
> that IBM WebSphere 3.5.4 on AIX is somehow broken
> or doesn't implement Servlet specification as it
> should? I'm quite sure that there is some other
> people who are using struts on WebSphere. Do you
> have this kind of problems when URL-rewriting is
> turned on?
> 
> Kind regards
> Aapo Laakkonen
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: URL rewriting and cookies

[Aapo Laakkonen]

I still have not got any answers for the problem described below.

Is there some problems with struts custom img-tag?

Why it is generating tags like this?



Where does this ';' came from and why there it is not '?' instead?

Do I have to add ? on every picture if I like to use URL rewriting instead
of cookies?

> > Could you post an example of the type of URLs you're seeing?
>
> Here is the struts -tag:
>
>  height="7" border="0"/>
>
> And it generates output like this:
>
>  height="7" width="715" border="0">
>
> As you see ";jsessionid=0001CEAAQCTISJFXCZWNZLC2WNA" is absolutely crap
that
> I don't want to have in src-attribute. This occurs only when I enable
> URL-rewriting and disable cookies in my application server (WAS 3.5.4 on
> AIX). I have WAS modified struts package installed.
>
> My client likes to use URL-rewriting and disable cookies... I'm not sure
if
> this problem occurs even if both URL rewriting and Cookies are enabled.
But
> again my client wants to use only URL-rewriting, because they have quite
> strict deployment standards.
>
> Images are not served by WAS as my client uses separate Web Server for
> serving static content and they don't want to have any overhead that is
> generated by WAS layer if the files can be served directly by Apache or
some
> other Web Server as it is the case with images in this app.
>
> Can someone at least confirm me if the problem exists in struts framework
or
> somewhere else so I can point my finger to the source of the problem...
and
> leave you to think how you can improve this great framework.
>
> Have you heard anything about WebWare for Python? I think that Struts
> developers should look at the ideas implemented in WebWare... if you
already
> have not. It's really nice app server ... at least in developer's point of
> view, imho.
>
> Original message:
> ---------
> I have some small problems with struts on WebSphere 3.5.4 on AIX.
>
> Everything works fine, if I enable cookies and disable URL rewriting. But
> when I enable URL rewriting and disable cookies (or maybe I just need to
> enable URL rewriting) struts is generating (or is it because of
> struts)strange URL's. For example if I have used  srcKey="image.logo"... /> tag then struts generates the tag correctly but
> adds session id at the end of HTML's -tags source attribute. And then
> the image is not displayed to the user because the generated URL points to
> wrong place.
>
> How can I remove struts from adding session ids at the end of the src
> attribute?



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

URL Rewriting / Jsessionid

[Justin Brister]

Please could some 
body help me? 
 
I am trying to 
create a simple HTML link which will pass a number of parameters through to a 
form. However, struts insists on inserting the Jsessionid into the link in such 
a way that it breaks the link. Is there anyway that I can either, build the link 
with the jsessionid inserted correctly, or turn off URL rewriting for the 
sessionid. I am trying to do this under Tomcat v 3.2.1. The code below is a 
simple test harness. What I am ultimately trying to do, is build links 
dynamically from a combination of data in properties files and a Database. Any 
assistance with this problem would be much appreciated.
 
 
<% String URL = "/3_0_products.jsp?" + ACTION + "="+ ACTIONS[0] + "&" + ID + 
"=1383602" ;%>
 
Accessories
 
Many 
thanks,
 
Justin Brister
Architecture & Performance Review 
Project Manager

[EMAIL PROTECTED] 
Tel : 020 7016 8000Fax : 020 7016 
8001


  

  mondus
 

This e-mail message is PRIVATE & 
CONFIDENTIAL and may contain LEGALLY PRIVILEGED information. It is intended 
solely for the addressee. Access to this message by anyone else is unauthorised. 

If you are not the intended recipient, 
any review, disclosure, copying, retransmission, dissemination, or other use of 
the information in this e-mail or any action taken or omitted to be taken in 
reliance on it is prohibited and may be unlawful.
Please telephone, fax or email us 
immediately and delete the message from your system. 
E-mail may be susceptible to data 
corruption, interception and unauthorised amendment. We do not accept any 
liability for any such corruption, interception or amendment or the consequences 
thereof.
We do not accept responsibility for the 
contents of this message and whilst any attachments to this message may have 
been checked for viruses, you should rely on your own virus checker and 
procedures.
 

How to use URL rewriting within frames?

[Hartmut Bernecker]

How to use RUL rewriting within frames?

Situation:
-

First frameset = "index.html".
Index.html defines a frame named "frame5".
The content of "frame5" is a JSP page that defines a new frameset!

How to do URL rewriting in that case??
In other words: I am missing a  tag in the Struts
framework!

Who can help?

TIA
Hartmut Bernecker

Apache/Struts URL Rewriting

[Jason Rosenblum]

I have an entire application that I wrote using Struts and Weblogic 5.1 SP8. I now 
need to run this app on top of Apache but I've run into a serious problem - URL 
Rewriting. Our Apache server forwards requests to Weblogic but it changes the url so 
accessing a URL like: localhost:8080/psr/index.do becomes 
localhost:8080/psr/index/0.html. Accessing the front door of the application on Apache 
then requires just changing the URL, but as soon as I submit a form, the application 
crashes because it's submitting my Actions as *.do instead of //0.html.

Is there any easy way to restructure my URLs using struts-config.xml or ActionMapping 
class?

~Jason

Re: URL rewriting

[Craig R. McClanahan]

On Thu, 5 Jul 2001, rajiv mulay wrote:

> if it is done internally, then if we disable cookies in browser
> session is not carried forward to other pages.
> 

Everything works as long as you understand the requirements defined in the
Servlet Specification, which can be downloaded at
<http://java.sun.com/products/servlet/download.html>.

Basically, the  and  tags automatically perform URL
rewriting for you.  But if you create any hyperlinks by other mechanisms,
you are totally on your own.

> rajiv

Craig McClanahan

RE: URL rewriting

[Tim Buchalka]

You 
need to check out the  custom tag to handle URL 
rewriting.
 
Refer 
to the online manual for details:-
 
http://jakarta.apache.org/struts/struts-html.html#link
 
Hope 
this helps.
 
Regards
 
Tim

  -Original Message-From: Eda Srinivasareddy 
  [mailto:[EMAIL PROTECTED]]Sent: Thursday, 5 July 2001 6:46 
  PMTo: [EMAIL PROTECTED]; suhasSubject: Re: 
  URL rewriting
  Hi 
  I also read some where in struts user guide, that the struts internally 
  handles the URL rewriting. But when we run our application which is perfectly 
  running when cookies are enabled is not running when cookies are disabled. 
  What might be the reason. 
  If u have any example which runs even if the cookies are disabled, please 
  forward it. 
  Thanks 
  Eda 
    suhas <[EMAIL PROTECTED]> wrote: 
  



it is done internally by struts tags  . 
That's one of the reason u are using struts tag instead of normal html tags 
.
Suhas
 

  - Original Message - 
  From: 
  rajiv mulay 
  
  To: [EMAIL PROTECTED] 
  
  Sent: Thursday, July 05, 2001 10:22 
  AM
  Subject: URL rewriting
  
  how to achive url rewriting in 
  sturts.
   
  rajiv
  
  
  Do You Yahoo!?Get personalized email addresses from Yahoo! Mail - 
  only $35 a year!http://personal.mail.yahoo.com/

Re: URL rewriting

[Eda Srinivasareddy]

 Hi 
I also read some where in struts user guide, that the struts internally handles the URL rewriting. But when we run our application which is perfectly running when cookies are enabled is not running when cookies are disabled. What might be the reason.
If u have any example which runs even if the cookies are disabled, please forward it.
Thanks
Eda
  suhas <[EMAIL PROTECTED]> wrote: 




it is done internally by struts tags  . That's one of the reason u are using struts tag instead of normal html tags .
Suhas
 

- Original Message - 
From: rajiv mulay 
To: [EMAIL PROTECTED] 
Sent: Thursday, July 05, 2001 10:22 AM
Subject: URL rewriting

how to achive url rewriting in sturts.
 
rajivDo You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!http://personal.mail.yahoo.com/

Re: URL rewriting

[rajiv mulay]

if it is done internally, then if we disable 
cookies in browser session is not carried forward to other pages.
 
rajiv

  - Original Message - 
  From: 
  suhas 
  To: [EMAIL PROTECTED] 
  Sent: Thursday, July 05, 2001 11:15 
  AM
  Subject: Re: URL rewriting
  
  it is done internally by struts tags  . 
  That's one of the reason u are using struts tag instead of normal html tags 
  .
  Suhas
   
  
- Original Message - 
From: 
rajiv mulay 

To: [EMAIL PROTECTED] 

Sent: Thursday, July 05, 2001 10:22 
AM
Subject: URL rewriting

how to achive url rewriting in 
sturts.
 
rajiv

Re: URL rewriting

[suhas]

it is done internally by struts tags  . That's 
one of the reason u are using struts tag instead of normal html tags 
.
Suhas
 

  - Original Message - 
  From: 
  rajiv mulay 
  
  To: [EMAIL PROTECTED] 
  Sent: Thursday, July 05, 2001 10:22 
  AM
  Subject: URL rewriting
  
  how to achive url rewriting in 
  sturts.
   
  rajiv

URL rewriting

[rajiv mulay]

how to achive url rewriting in sturts.
 
rajiv

Re: Deactivate URL-rewriting in logoff action.

[Ana Narvaez Vila]

What I was trying to say is that when logoff action is called, my
application ends and the user goes to another location. Although I
invalidate() session in logoff, when ActionServlet forward to next page
creates a new session that is not really used by anyone.

For example, I want user to go to www.altavista.com after logoff action
so I don't need new session.


http://altavista.com"
redirect="true" />


Thaks

"Craig R. McClanahan" wrote:
> 
> On Thu, 15 Mar 2001, Ana Narvaez Vila wrote:
> 
> > Logoff action usually invalidates session and sends browser to a index
> > or welcome page, so it is not necesary to rewrite the URL.
> >
> > ActionServlet must have a session, so if there isn't a valid session it
> > creates one.
> > Question is: Is there a way to say to ActionServlet not to create a new
> > session ?
> >
> 
> It's not just the controller servlet that creates sessions -- JSP pages do
> as well, unless you tell them not to with a page directive:
> 
> <%@ page session="false" %>
> 
> However, trying to run Struts based apps completely without sessions is
> going to cause you some grief in the following areas:
> 
> - Internationalized message lookups in the 
>   tag depend on a Locale object stored in the user's session,
>   which indicates this user's current Locale preference.
> 
> - The  mechanism for displaying validation errors
>   relies on the same thing, so you cannot use this.
> 
> My advice would be to go ahead and let the sessions be created, and
> minimize the memory occupancy by using request scope (rather than session
> scope) for all your application's form beans.  We're talking tens of bytes
> per simultaneous user for the session itself (and the associated Locale),
> so the memory requirements are not onerous -- even if it took 100 bytes
> per user, 10,000 simultaneous users is still only a megabyte.  And you are
> pretty much certain to run into other resource limits (CPU, database,
> network) before you reach that many users anyway.
> 
> Craig
--
This email is confidential and intended solely for the use of the individual to whom 
it is addressed. Any views or opinions presented are solely those of the author and do 
not necessarily represent those of Sema Group. 
If you are not the intended recipient, be advised that you have received this email in 
error and that any use, dissemination, forwarding, printing, or copying of this email 
is strictly prohibited.
--

Re: Deactivate URL-rewriting in logoff action.

[Craig R. McClanahan]

On Thu, 15 Mar 2001, Ana Narvaez Vila wrote:

> Logoff action usually invalidates session and sends browser to a index
> or welcome page, so it is not necesary to rewrite the URL.
> 
> ActionServlet must have a session, so if there isn't a valid session it
> creates one.
> Question is: Is there a way to say to ActionServlet not to create a new
> session ?
> 

It's not just the controller servlet that creates sessions -- JSP pages do
as well, unless you tell them not to with a page directive:

<%@ page session="false" %>

However, trying to run Struts based apps completely without sessions is
going to cause you some grief in the following areas:

- Internationalized message lookups in the 
  tag depend on a Locale object stored in the user's session,
  which indicates this user's current Locale preference.

- The  mechanism for displaying validation errors
  relies on the same thing, so you cannot use this.

My advice would be to go ahead and let the sessions be created, and
minimize the memory occupancy by using request scope (rather than session
scope) for all your application's form beans.  We're talking tens of bytes
per simultaneous user for the session itself (and the associated Locale),
so the memory requirements are not onerous -- even if it took 100 bytes
per user, 10,000 simultaneous users is still only a megabyte.  And you are
pretty much certain to run into other resource limits (CPU, database,
network) before you reach that many users anyway.

Craig

Deactivate URL-rewriting in logoff action.

[Ana Narvaez Vila]

Logoff action usually invalidates session and sends browser to a index
or welcome page, so it is not necesary to rewrite the URL.

ActionServlet must have a session, so if there isn't a valid session it
creates one.
Question is: Is there a way to say to ActionServlet not to create a new
session ?

Thanks
--
This email is confidential and intended solely for the use of the individual to whom 
it is addressed. Any views or opinions presented are solely those of the author and do 
not necessarily represent those of Sema Group. 
If you are not the intended recipient, be advised that you have received this email in 
error and that any use, dissemination, forwarding, printing, or copying of this email 
is strictly prohibited.
--

html:img tag url rewriting

[Deadman, Hal]

When using the 
html:img tag with the page attribute it will do url rewriting but that doesn't 
seem to work on some webservers. 
 
This doesn't 
work:
http://jakarta.apache.org/images/logos/tomcat_3.gif;jsessionid=123123
 
Is there a way to 
turn off the url rewriting and have the img tag still add the appropriate 
context to the image path?
 
Hal