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.

Similar Messages

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
          >

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...

ACE module SSL url rewrite and path rewrite

Hi all,
I'm hoping some of you helpful people on this forum can guide me or suggest a solution to a problem I'm faced with.
I am currently load balancing exchange 2010 traffic via an ACE module. Software version is A2(3.3). I have most parts of it working fine however I am having an issue when it comes to SSL termination for Outlook Web Access (OWA).
The problem comes down to a HTTP header (field is location). I have configured an action list to re-write the SSL pure URL as per page 96 of the "Cisco Application Control Engine Module SSL Configuration Guide". example:
ssl url rewrite location bnecas\.mycompany\.com sslport 443
That part works, the http header location field that comes back from the GET request is changed to https://cas.mycompany.com which is great. However, in addition to that url, there is also a path or something following that part. The actual string that is returned is:
https://cas.mycompany.com/owa/auth/logon.aspx?url=http://cas.mycompany.com/owa/&reason=0
The first bit of it, (https://cas.mycompany.com) is changed by the ssl url rewrite command, however the last part (http://cas.mycompany.com/owa/&reason=0) isn't changed.
This is where I've been trying to get the http Header Rewrite command to do something. I don't know if it can work in conjunction with the ssl url rewrite function however with the ssl rewrite function it seems it can't change bits of the string that aren't the pure URL at the front.
The end result is that while I have an SSL connection to the OWA login page, when I do login to OWA it reverts back to HTTP. I'm fairly sure it is because of the last part of the location string above. Is there a way to change that location string to do the following:
1. change the first part of the string to be https://cas.mycompany.com (like the ssl url rewrite function)
2. change the last part of the location string to put https in there instead of http
Ideally I would love to have this string
http://cas.mycompany.com/owa/auth/logon.aspx?url=http://cas.mycompany.com/owa/&reason=0
replaced with this one
https://cas.mycompany.com/owa/auth/logon.aspx?url=https://cas.mycompany.com/owa/&reason=0
I had originally tried the following in the action list:
header rewrite response location header-value "(owa/auth/logon\.aspx\?url=)http(://bnecas\.thiess\.aus/owa/&reason=0)" replace "%1https%2"
ssl url rewrite location bnecas\.mycompany\.com sslport 443
but it didn't work. I'm probably screwing up the regex somewhere however there doesn't seem to be very clear examples anywhere I can find.
Any help will be greatly appreciated and of course I will be sure to rate every post that responds to my plea for help.
Brad

Hi Brad,
try this:
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
action-list type modify http X
header rewrite response Location header-value "http://(.*url=)http://(.*)" replace "https://%1https://%2"
we wont be using ssl url rewrite in this case
Also we will be needing persistence rebalance applied through application parameter map and apply that under the VIP class

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.

JavaScript URL rewritting and screen blinking

Hi Experts,
I am working with EP and JavaScripts. We are making changes through JavaScript in Portal.
I have to rewrite the URL's with new URL's by using JavaScript. I am using the following code-
if( parent.document.body.innerHTMLindexOf(URL)>0)
rewriteLinks(sourceURL,targetURL);
if( parent.document.body.innerHTMLindexOf(URL)>0)
rewriteLinks(sourceURL,targetURL);
f( parent.document.body.innerHTMLindexOf(URL)>0)
rewriteLinks(sourceURL,targetURL);
But, the problem is screen is blinking for 3 times to execute the above 3 if()conditions. I think, for every if() the screen is reloading.
How to stop reloading for every if() condition? Once all the if() conditions executed, then only reload the screen.
Regards,
Vijay.

Hi Vijay,
It sholun't happen in javascript.U have put 3 conditions same as per the code u send.Check that once.
Any u can stop blinking in javascript.Refer this.
http://www.w3.org/TR/WCAG20-TECHS/SCR22.html
Regards,
Srikanth

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))

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

APEX: Internet domain mapping / URL rewrite for Apps in the cloud

Hello,
I have registered for a trial access since first day in which the cloud was launched ... But, did not get access till now ... If I were to buy it, am I going to get access right away ??
Is Oracle Cloud going to offer Internet domain name mapping to a specific APEX application ???
Is Oracle Cloud u going to offer URL rewrite where APEX URL is not Search Engine friendly.... e.g:
This site: http://www.enkitec.com/ was built on APEX, but as you can see the URL was rewritten ????
Best Regards,
Fateh

Hi,
According to your post, my understanding is that the rule was not processing for SharePoint 2013 result page.
Please make sure you add the reverse rewriting rule correctly.
For more information, you can refer to:
Add the reverse rewriting rules (in the HTML)
Setting up a Reverse Proxy using IIS, URL Rewrite and ARR
Best Regards,
Linda Li
Linda Li
TechNet Community Support

Url rewriting & pagination

I am in the process of learning url rewriting, and with the help of a great book, 'Professional search engine optimization with PHP', i have got as far as rewriting category and product url's into keyword rich ones.
example at http://www.blunique.co.uk/Earrings-C1.html
where i am struggling is rewriting the url when i have the recordset results paginated, (using dreamweaver standard server behavior for repeat region).
Grateful for any advice.

Greetings,
I'll tailgate this similar question; I could use a guide to WLP 81x URLs. What does each parameter mean in file mode (.portal) and stream mode?
Any help here? Tips for understanding URLs would help Anders too.
tnx, curt

Regex help for URL rewriting

I have the following regular expression for rewriting a URL (from existing code which I had to make some quick changes)
String regex = "s#(href|src|url|action|background)=(\"?)(/|" + "http:originalserver.com" +"/|http.?://" + "originalserver.com"+ ")([^\">]*?)(\"?)#$1=$2" + "myserver.com" + "/$4$5#gis";
which does a URL rewrite and changes the URL from something like
src="http://originalserver.com/images/someimage.gif" to
src="http://myserver.com/proxy/images/someimage.gif"
Now I want to change this regex to add some parameters to the URL. ie.
case 1:
href="http://www.originalserver.com/index.htm"
to
href="http://www.originalserver.com/index.htm?myParam1=myValue1
case 2:
href="http://www.originalserver.com/index.htm?originalP1=originalV1"
to
href="http://www.originalserver.com/index.htm?originalP1=originalV1&myParam1=myValue1"
How can I change the regex to do this. As I have to do this fast and not an expert in Regex, any help would be appreciated.

Hi,
try this :
- first set delimiter (? or &) to append your parameters :
char delimiter = '\?';
String myParams = "myParam1=myValue1";
Pattern p = Pattern.compile( "\?" );
Matcher m = p.matcher( url );
if( m.matches() )
delimiter = '\&'; // not sure ampersand needs to be "backslashed"
- then use the modified regex
String regex = "s#(href|src|url|action|background)=(\"?)(/|" + "http:originalserver.com" +"/|http.?://" + "originalserver.com"+ ")([^\">]*?)(\"?)#$1=$2" + "myserver.com" + "/$4$5" + delimiter + myParams + "#gis";

URL rewrite now working for SharePoint 2013 result page

Hi,
I have configured reverse proxy using URL Rewrite (ARR), all works fine but the rule is not processing for SharePoint 2013 result page. It still shows internal domain name and not external domain name.
this is my web.config in internet web server
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<outboundRules>
<rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsHtml1">
<match filterByTags="A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script" pattern="^http(s)?://dsplsp2013/(.*)" />
<action type="Rewrite" value="http{R:1}://uncep/{R:2}" />
</rule>
<preConditions>
<preCondition name="ResponseIsHtml1">
<add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
</preCondition>
</preConditions>
</outboundRules>
<rules>
<rule name="ReverseProxyInboundRule1" stopProcessing="true">
<match url="(.*)" />
<action type="Rewrite" url="http://dsplsp2013/{R:1}" />
<serverVariables>
<set name="HTTP_ACCEPT_ENCODING" value="" />
</serverVariables>
</rule>
</rules>
</rewrite>
<urlCompression doStaticCompression="false" />
</system.webServer>
</configuration>
Thanks
Hari
Hari

Hi,
According to your post, my understanding is that the rule was not processing for SharePoint 2013 result page.
Please make sure you add the reverse rewriting rule correctly.
For more information, you can refer to:
Add the reverse rewriting rules (in the HTML)
Setting up a Reverse Proxy using IIS, URL Rewrite and ARR
Best Regards,
Linda Li
Linda Li
TechNet Community Support

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

URL writing and Cookie

Can you use both methods for maintaing the session id in a web application.
For example, use session id from the cookie in most cases and in some case use the id from URL and bind the request to session.
Is it possible to do it ?

If you take a look at the API http://java.sun.com/j2ee/1.4/docs/api/index.html for javax.servlet.http.HttpServletResponse.encodeURL()
it says the following
Encodes the specified URL by including the session ID in it, or, if encoding is not needed, returns the URL
unchanged. The implementation of this method includes the logic to determine whether the session ID
needs to be encoded in the URL. For example, if the browser supports cookies, or session tracking is
turned off, URL encoding is unnecessary.
For robust session tracking, all URLs emitted by a servlet should be run through this method. Otherwise,
URL rewriting cannot be used with browsers which do not support cookies.Thus it will ONLY add the id from URL if it detects that the browser does not support cookies.
Cheers,
evnafets

URL Rewriting Session ID Length in iPlanet Application Server

Hi there,
Does anyone know what the maximum length of the session ID value is when
using URL rewriting/encoding for session tracking (i.e.: ";jessionid=1234"
appended to the end of the URL) with iPlanet Application Server 6.0's
servlet container (or any previous versions)?
Does the length vary or is it fixed? And does WebSphere encode server or
failover information into the ID? WebLogic for instance, encodes the
primary and secondary failover servers into the ID when running in a
cluster)?
And finally, is there any way to restrict or specify the maximum length of
the session ID?
I ask this due to a limitation with some WAP clients & gateways which
prevents the URL from exceeding 128 characters.
Any info on this issue from iPlanet staff or anyone else is much
appreciated.
<background-info>
Please see the following links if you'd like some additional background:
http://e-docs.bea.com/wls/docs60/////wap/wapdev.html#1024984
under the heading "Session Tracking" at the bottom
http://groups.google.com/groups?hl=en&safe=off&th=eb7f38aa5086972e,13&seekm=
8gaki8%247d5%241%40newsgroups.bea.com#p
</background-info>
Regards,
Sasha Haghani

Sasha Haghani wrote:
Hi there,
Does anyone know what the maximum length of the session ID value is when
using URL rewriting/encoding for session tracking (i.e.: ";jessionid=1234"
appended to the end of the URL) with iPlanet Application Server 6.0's
servlet container (or any previous versions)?
I'm fairly certain that it is fixed. 18 for the attibute, 16 for the value, plus
1 for the equals. (Plus 1 for the ? if it didn't already exist.)
So 35 or 36 depending on how you count it. Someone needs to verify this and
check my counting though.
>
Does the length vary or is it fixed? And does WebSphere encode server or
failover information into the ID? WebLogic for instance, encodes the
primary and secondary failover servers into the ID when running in a
cluster)?I don't know what WebSphere does. iAS does not encode failover information in
the ID. Because of the way session is propogated, no server information needs to
be embedded in the id.
>
And finally, is there any way to restrict or specify the maximum length of
the session ID?No.

Cookies, URL-Rewriting, and Sessions

Similar Messages

Maybe you are looking for