Cookie / url rewriting doubt

1) Browser cookie support enabled.
Request first sent & server sets the session ID as cookie in the HTTP response header.
2) Browser sends the cookie back while making the next request to the server. Now the server picks up sessionID cookie and thus the client joins the session.
3)
Response sent with session ID as cookie and not URLencoding since you found that cookie was enabled last time.
4) All of a sudden Browser cookie support disabled.
So what will happen now since for next subsequent request cookie disabled and also url is not rewritten with sessionID in the html response we got from the server. So will that session be lost?
Do we have any protection against this scenarion?

I don't know what will happen. Probably the new request will not participate in the old session. But the chances that somebody will turn off cookies in their browser while accessing your site is extremely small. So if you really need to know, it wouldn't be hard to try it.

Similar Messages

Cookies, URL-Rewriting, and Sessions

Hi All,
I am aware that this is probably a question that has been asked many times in the past. Nonetheless, I have not been able to fully comprehend the differences. Therefore I would appreciate it, if someone could kindly spend some time explaining the differences between the three and when each would be the most preferred solution. ( cookies, url rewriting and sessions )
So far what I understand is that, cookies can be used to store small amounts of data not more than 4kb, and that most browsers can not accept more than 20 at a time.... but would it be correct to say that the data is stored within the http headers ?
URL rewriting, on the other hand is a method which can be used if cookies have been disabled by a browser. The 'session id' is appended to the url, and used to remember the data. ( how ? ). Although, it does mean that the programmer has to be very careful and ensure that rewriting occurs everytime it is passed to the browser, including redirection. ( whatever that means ? )
Http sessions, seem to be the best solution out of the three ( but if this is the case, why are cookies and rewriting still hanging around today ? And even being taught at universities ? ). Also, they work on top of cookies and if these have been disabled sessions will not work !! ....
As you can see ( from the above ) I do not have a thorough understanding of the three methods, especially if it comes to specifying the differences between the three.
I would appreciate an explanation.

HttpSessions use cookies or url rewritting to pass the session id which the server uses to associate a particular session with a particular request. A well developed web application will be written to use url rewriting when a client has cookies disabled. That being said I yet to see such a web application and personally believe that few people still disable cookies.
Cookies still have uses.
Persistant cookies are used to store data that needs to persist between sessions. This data is stored by the browser in a text files and passed to the server in the header. An example of this would be a site that offers personalization would store the user's id so that each time the user accesses the site he would see his personalization without being required to log in. Yahoo is a good example.
In memory cookies are stored in the browser's memory and is used to store temporary data that goes away when the browser closes. Again this data gets passed to the server in the headers. Temporary cookies can be used to pass data between seperate web applications runing on the same host where storing the data in the session will not because each application has it's own session.

Sessions, URL Rewriting, and Cookies

First some background, then some questions:
          BACKGROUND
          I have written an application framework to use with JSP/EJB/Servlet
          based applications. This framework does URL rewriting
          (response.encodeUrl) for all URLs generated by the application, and I
          have URL-based session support turned on in WebLogic.
          Despite the fact that my browser is set to support cookies on my test
          machines, I have noticed that intermittently the URL rewriting to
          support session IDs kicks in. Then, later, it goes away again. This
          would seem to indicate that the client browsers are (for no apparent
          reason) deciding to occasionally not support sessions with cookies, so
          that the server has to step in and do URL writing instead.
          QUESTIONS
          1. Has this sort of behavior been reported by anyone else?
          2. Is there a servlet/JSP API anywhere that I can call on a per-HTTP
          transaction basis to see if the browser that is participating in the
          transaction is at that moment supporting cookies?
          3. There are times when my framework needs to delete a cookie by setting
          its maxAge to 0. Most of time time this works, but (as with the session
          ID/URL rewriting above) occasionall the cookie does not get deleted on
          the client brower machine. This screws up some of the application logic
          that I have in the framework. Is this related to the problems listed
          above?
          CONCLUSION
          Any and all information is appreciated, from anyone. Thanks!
          Chris


          Hi,
          To answer your question #1, yes I have seen this behaviour, and
          the explanation I feel is as follows.
          1] You access a resource on WL Server & it starts a session, at
          this moment it is not sure whether the browser supports cookies
          so it uses both methods, URL Writing & cookies to store the session
          ID
          2] On the next request, it tries to read the cookie, if it is able
          to read it that means cookies are enabled and there is no need
          to continue with URL Rewriting else it continues wioth URLRewriting.
          To answer Question #2, you can follow a procedure similiar to above
          to find out if browser supports cookies, ie set a cookie & in the
          next request try to read teh value.
          As far as Question #3 is concerned, try setting the magAge to -12
          hours insteda of 0 so that there is no problem even in case of
          a time difference.
          hope this helps
          Rahul
          Chris Dole <[email protected]> wrote:
          >First some background, then some questions:
          >
          >BACKGROUND
          >I have written an application framework to use with JSP/EJB/Servlet
          >based applications. This framework does URL rewriting
          >(response.encodeUrl) for all URLs generated by the application,
          >and I
          >have URL-based session support turned on in WebLogic.
          >
          >Despite the fact that my browser is set to support cookies
          >on my test
          >machines, I have noticed that intermittently the URL rewriting
          >to
          >support session IDs kicks in. Then, later, it goes away
          >again. This
          >would seem to indicate that the client browsers are (for
          >no apparent
          >reason) deciding to occasionally not support sessions
          >with cookies, so
          >that the server has to step in and do URL writing instead.
          >
          >QUESTIONS
          >1. Has this sort of behavior been reported by anyone else?
          >
          >2. Is there a servlet/JSP API anywhere that I can call
          >on a per-HTTP
          >transaction basis to see if the browser that is participating
          >in the
          >transaction is at that moment supporting cookies?
          >
          >3. There are times when my framework needs to delete a
          >cookie by setting
          >its maxAge to 0. Most of time time this works, but (as
          >with the session
          >ID/URL rewriting above) occasionall the cookie does not
          >get deleted on
          >the client brower machine. This screws up some of the
          >application logic
          >that I have in the framework. Is this related to the problems
          >listed
          >above?
          >
          >CONCLUSION
          >Any and all information is appreciated, from anyone. Thanks!
          >
          >Chris
          >

If user disable cookie how to set and use session with URL Rewritting

if user disable cookie how to set and use session with URL Rewritting by append session ID in url

If cookies are disabled, then app server will automatically try to use URL rewriting for session control. Programmer's responsibility is to encode any links or redirects using
response.encodeURL("/yourPage.jsp")
and
response.encodeRedirectURL("/yourPage.jsp")
See API for details
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpServletResponse.html#encodeURL(java.lang.String))

J2EE: Explanation of URL rewriting?

Hi there fellow forumites,
I'm reading up on the implicit object Session in regards to JSP. Session state is usually done by maintaining a cookie that is sent to the client. If clients have cookies disabled, the Session object falls back on a method called "URL rewriting" to maintain state across many request/response calls. I've googled for this and searched the forums, but the web results are deeply technical and seem specific to ASP.NET and Apache modules and I've found nothing satisfactory in forum posts that explain it.
Can someone give a short description on how this "URL rewriting" works and why I need to rewrite any embedded URLs with the appropriate Response object methods?
Is it encoded in the HTTP header like parameters or something?
Thanks all.

i can't answer that, i've never actually written
anything with j2ee. if you mean will they
automatically append to any url you write (with
Response.Write (or similar))? I doubt it. you
probably have to do it yourself, or call some
"WriteURL" function.Thats the methods of the Response object I was referring to (encodeURL(String)). Sorry, I didn't realise you'd not done any J2EE, so I was rabbiting on and assuming that you knew what I was on about :) I think I've answered my own question on that with your help, so thanks again.

URL rewriting for a WebService Consumer Proxy

Hi all,
Did anybody come across this issue?
I have a SAP System - let's call it "TM" - that I want to bind with another non-SAP one - let's call it "FB" - without any PI between them.
The communication is made as a Service Consumer (TM side), the Proxy (see image below) and Proxy-Implementation Class being generated automatically after the ".wsdl" file and the "url" given by the documentation of FB.
Everything looks good! All the Methods (operations) that are available from the service have been added to the Implementing Class.
After the Proxy generation, I also created the Logical Port (in transaction SOAMANAGER - see image below) where the path, host, prefix, and all the necessary stuff were also automatically created after the ".wsdl" document.
So far so good! When I want to test it and to play along with this connection TM -> FB, I am creating the Proxy-Object, I am filling the required User / Pass / and an ID in order to call the first method. As you have probably guessed already: LOGIN.
    ls_in_login-login_request-id             = '...some ID...'.
    ls_in_login-login_request-user          = '...some user ...'.
    ls_in_login-login_request-password = '...some password'.
TRY.
         CREATE OBJECT lo_proxy
           EXPORTING
             logical_port_name = 'ZAS_PORT_FB'.
     CATCH cx_ai_system_fault INTO lo_ref.    " Application Integration: Technischer Fehler
ENDTRY.
   TRY.
       CALL METHOD lo_proxy->login
         EXPORTING
           input = ls_in_login
         IMPORTING
           output = ls_out_login.
     CATCH cx_ai_system_fault INTO lo_ref.    " Application Integration: Technischer Fehler
     CATCH cx_ai_application_fault INTO lo_ref.    " Application Integration: Applikations Fehle
ENDTRY.
As a response, (meaning that the connection works and that the WebService acknowledges the connection) I get a "SessionID" -> a string of characters.
In the Wiki of the Service is written that from this point on, every other methods (but I mean ALL of them, logout() also...) need to be called along with this SessionID. The problem is, that this SessionID doesn't have a specific place in the "inbound"-structure of the methods, but this mechanism of passing around the SessionID must be made with URL rewriting. Another solution would be to use COOKIES. From my point of view, a so-called URL rewriting would be easier, right?
In the documentation is the following info written:
URL rewriting (recommended):
The JSessionId is attached to the URL of the SOAP request, as follows: http://[URL];jsessionid=[jsessionid]
Caused by tecnical reasons, it is necessary to specify the static string “;jsessionid=” in lower case letters.
I have turned this "LO_PROXY" object around and around and around... trying to find a solution... a method...anything that would let me rewrite the URL, but nothing...
I have also tried to use ce CL_HTTP_CLIENT class and to create myself the client and the URL and the host and everything manually... but in this case how do I end up in calling a specific "custom" method -> for instance... how do I call the "LOGIN"... or the LOGOUT...where do I put the parameters, etc?
Do you have any suggestions / ideas / hints ?
Thanks a lot in advance!
Warm regards,
Alex

Hi Stefan,
You are right! It doesn't support to set URL / HTTP parameters outside the logical port.
Nevertheless, I have debugged the whole engine and found out that via custom coding (enhancements / modifications) and with extreme attention, the URL can be rewritten as desired.
When a method of the proxy is called, let's say for instance: lo_proxy->logout (...) - as written up for example, the method CL_HTTP_CLIENT=>CREATE_BY_URL is called dynamically.
In this method, in the "url" variable is the desired URL that needed to be rewritten.
Here it's about an importing parameter, so it cannot be changed so easily, but it's not impossible.
Another place where a nice Enhancement can be created is at the beginning of the FM "SWLWP_URI_PARSE".
You need to be very careful not to change these places in all cases (this CREATE_BY_URL will be called pretty much), JUST when the specific conditions are fulfilled.
Have a great day / week!
Warm regards,
Alex

URL rewriting issue

Hello all,
I am having a url rewriting issue where the first time someone accesses the website with a browser that has cookies enabled my jsp pages will still encode all of the URL's with the jsessionid. Which I believe should not happen unless cookies are disabled.
Why is this occuring?
Once the user goes to another page in the site or the second time they bring up the site in the same browser the jsessionid is not written to the URL links. This only happens on first access.
I am using Tomcat 5.5
response.encodeURL() to encode the links
Is this a container or programming error?
Thank you all very much for your time in reading this!

Ok, thank you.
Based on this: http://www.sciabarra.com/fatwire/2011/04/17/improving-the-firstsiteii-url-assembler/
I think my approach would work if I remove the Asset API stuff from here and put them into a helper class, which would be then called from the wrapper JSP.
I'd rather not install 3rd-party extensions just for url rewriting, at least not yet...

URL Rewriting in JSF 1.2

Hello,
I am new to JSF. I am using JSF 1.2. I basically need URL rewriting in my JSF pages.
I need to rewrite all Links in JSF by which jsessionid will attached to links in similar way to html:rewrite/html:link in struts .
How do i achieve this in JSF 1.2. I heard PrettyFaces does good job in this area but is there any other simple way to URL Rewriting in JSF?
Thanks in advance
Subbarao

JSF will do this automatically if it detects that the session cookie has not been set. (Really this is being done by the servlet infrastructure.) You need to make sure you are using JSF components to output all of the links, buttons, etc. If you need a link otherwise, use the methods on HttpServletResponse to encode the URL.
I think the configuration for declaring that your application should not use cookies is application server specific.

URL Rewriting in JSP/Servlets

Enabling URL rewriting for session support where cookies are switched off, results in the URL being rewritten as myURL/$SessionID$a_very_long_string.
I believe that the /$SessionID$ is configurable on the server, does anyone know how ?
OAS version 4.0.8.1. patched with JSP support.

Why is it placing a ';' before jsessionid ? Shouldn't
it be a '&'? The current result is a page not found.Your url looks ok to me. '&' seperates parameters. I'm using the Struts framework to handle those ugly details and it generates urls like this one for me:
http://localhost:8080/JspMini/main.jsp;jsessionid=C2C1C2D9C6106758047127038554C813
Looks like you have another problem...
HTH, Markus

Always use URL Rewriting for session tracking?

All you JSP guru:
I am working on a JSP project that requires session tracking. I have successfully implements session tracking with both cookies or URL rewriting. I know that with the HttpSession object, it will always try to use cookie first, if that's disabled, then it'll automatically switch to URL rewriting. However, is there a way to force the HttpSession object to ALWAYS use URL rewriting instead of cookies? I have searched for an answer for a long time and haven't been able to found a solution. Is it possible at all? Thank you very much.

i was going to say that WebSphere always uses URL rewriting if you enable it at all, but someone beat me to it (indirectly) :-)
however, that seemed to me to be a violation of the spec, which seemed to imply the behaviour you're describing (only use URL rewriting if cookies are not supported on the current client)
here's a response someone else made on a websphere newsgroup to a statement in that regard:
I believe you are technically correct. However from my
experience, I think the spec if flawed in this area since
there is no reliable way of determining whether the
client browser supports cookies. The authority on
cookies (www.cookiecentral.com) says:
"To properly detect if a cookie is being accepted via
the server, the cookie needs to be set on one HTTP
request and read back in another. This cannot be
accomplished within 1 request."
This is asking too much of a servlet engine
implementation. Even if it did submit a request for this
purpose, the user could refuse the cookie. So
then technically the browser supports cookies, but the
servlet engine infers it doesn't. So if the servlet engine
infers the browser does not support cookies and so
encodes the URL, it is again out of spec because the
browser really does support cookies. By doing it
however encoding is configured makes things simpler,
robust, consistent and avoids the flaw.
My opinion.so, mostly i'm just rambling, but if you're using websphere, you should get the behaviour your boss wants. if you're using something else, i suppose there's a chance it'll "violate" the spec in this same, potentially helpful way.
btw, i remember somebody else complaining that URL rewriting is less secure than cookies, but i kinda think they're about equal. it seems like either could be intercepted by a sniffer and then used to spoof. but i'm no expert in that stuff...

Does URL rewriting in JBuilder4 work?

I am writing a shopping cart application.
To keep track of the products the user has chosen I am using a URL rewriting code that appends the product details to the URL and then requests the same page again.
<a href="<%= response.encodeURL(shopproducts.jsp?title="+title+"&item_id="+item_id+"&price="+price) %">">
In this page there is a response that will add the chosen product to the shopping cart using a piece of JSP code.
<% String title = request.getParameter("title");
In JBuilder4 when I click on the request code I get an error.
Unable to open location: Could not connect to: http://localhost:8080/myproject/easyshop/shopproducts.jsp;jsessionid=To1010mC02444678198891448At?title=Java 2&item_id=1&price=10
Is this because JBuilder dosent know how to keep track of the session ID?
If so how can I get round this or if not is there a better way to keep track of the items?
thanks.</a>

Take a look at UrlRewriteFilter for URL Rewriting.
This particular URL http://localhost:8080/myproject/easyshop/shopproducts.jsp;jsessionid=To1010mC02444678198891448At?title=Java 2&item_id=1&price=10
has ;jsessionid=.............. after shoppingproducts.jsp
But a valid URL looks something like this
somepage.jsp?someValue=123&anotherValue=456
So having that semicolon instead of a question mark immediately after the .jsp , might be what's causing the error.
If you have doubts , try to access the page by putting the entire URL
http://localhost:8080/myproject/easyshop/shopproducts.jsp;jsessionid=To1010mC02444678198891448At?title=Java 2&item_id=1&price=10
into your browser.
If your browser can't connect then, what ever you are using to connect to that URL can't connect either.
Then remove the semicolon and jessionid part, and try to connect and see if it works.

URL Rewriting & Mozilla

I've noticed some functional changes between SJSAS 8 Update 1 and SJSAS 8 2004Q4 Beta regarding use of URL rewriting in webapps.
Our servlet explicitly disables cookies in preference for URL rewriting. In SJSAS8-Update1, as for every other app server we've used (SJSAS 7 2004Q2, S17AS, Weblogic 8, Jboss), this works fine. But in the 2004Q4 beta release, URL rewriting doesn't work in Mozilla. IE works as per usual - inserting the relevant jsessionid's in the address bar.
Consequently when the browser attempts to hit the servlet for the second time - it has no jsessionid, and the servlet doesn't recognize the session.
As I said, this isn't a problem with any other release of the product; it seems to have been introduced in this most recent 2004Q4 beta of S1JSAS 8.
Anyone else noticed this or have any suggestions?

More specifically, the problem appears to exist -only- in Firefox (not Mozilla in general).
Using LiveHTTPHeaders, its clear that Firefox 1.0 is setting the jsessionid identifier as a cookie, as opposed to URL rewriting. The other parameters are correctly passed using URL rewriting.
Thus Mozilla is sending a URL without the jsessionid and the appserv web container cannot locate the session.
We've set our sun-web.xml file to disable cookies explicitly using "enableCookies=false". However, Sun Appserv 8.1 2004Q4 BETA sends back a cookie to Firefox's request - even though the webapp has disabled it...
Very frustrating!! Any help/suggestions would be gladly appreciated!

WLS 6.1 SP1 URL Rewriting Still Not Working?

          Anyone having success with URL Rewriting? The SessionServlet example is STILL
          not working for me when cookies are disabled. New sessions are created every
          access and the counter never increments past 1.
          Any info would be appreciated.
          Regards, Jeff


          The SessionServlet example works fine for me. By default URL re-writing is enabled
          and it will come into picture if the browser doesn't accept cookies.
          Try the examplesWebApp which is in 'examples' domain. It has SessionServlet as
          part of it.
          Sathish Santhanam
          Developer Relations Engineer
          BEA Support

Please explain this about URL rewriting

I am trying to write a simple example to understand URL rewriting...
On Test1 Servlet in the doGet I have the following
               HttpSession session = req.getSession(true);
               session.setAttribute("userid","123");
               String url = resp.encodeURL("Test2.jsp");
               System.out.println(url);
               resp.sendRedirect(url);In the Test2.jsp I have the following
<P>OK......</P>
<%String id = (String)session.getAttribute("userid");%>
<%=id%>Even though I see the URL being appended like
http://localhost:9080/urlTest/Test2.jsp;jsessionid=00006O173z1PBf6mXOujvK25iJc:-1
and I also see the result 123 on the screen...
How do I know that its not using HttpSession and its using URL rewriting?

The call to encodeURL is what is putting the "jsessionid" section into the URL. That is what it is using to maintain the session.
So it IS using HTTPSession, but the sessionid is being maintained via URL rewriting, rather than with a session cookie.
As an experiment, take out the call to "resp.encodeURL()" and see what the result is.
Also, if you are using the url to redirect to, you should be using the method response.encodeRedirectURL. The rules for encoding a url being used as a redirect are slightly different from one being used as a link on a page.

Unable of keep session using url rewriting tomcat

Hi everybody,
I have an application which communicates with a servlet. I am trying to use session tracking for my midp application with the url rewriting technique because of simplicity. I have tomcat 4.0.3 and MIDP 2.0. I had forced the use of url rewriting including this line into the server.xml file from tomcat:
<Context path="/webappname" debug="0" cookies="false" docBase="webappname"/>
This should force url rewriting, but when i call the method encodeURL in my servlet i only get a void
string. I know this isnt the best forum for this, but i have to try ;-). Any suggestion? all comments will be wellcomed, but please i dont want to use cookies and the rms api.
Thanks.

Are you aware that the MIDlet's networking won't support cookies or redirections automatically, and that you have to code that yourself: reading the "set-cookie" header and saving it for later, or catching redirection response codes (3xx) and changing the url accordingly?
Check out these tutorials:
http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-wireless.html
http://developers.sun.com/techtopics/mobility/midp/articles/servlets/
shmoove

Cookie / url rewriting doubt

Similar Messages

Maybe you are looking for