The javadoc for javax.servlet.http.HttpServletResponse is a little vague on the difference between what rules encodeURL and encodeRedirectURL follow, are there any examples of what those exact rules are? When will the output of encodeURL differ from encodeRedirectURL?
For a concrete example, I am already generating a redirect url that I will use with response.sendRedirect(url). I get that url already encoded, but I want to add a parameter to it which has a value that is another url:
param2=http://google.com
Which of the two functions do I use to encode this?
Salam Alekom Abduallah,
I looked and looked for an answer I knew I would find it in either stackoverflow or coderanch and there I found the answer from Charles Lyons the author of the book in my hand right now it was a cheerful coincidence.
posted 8/9/2008 11:41 AM
Exactly - the difference being that encodeURL always writes the
session ID into the URL (if required e.g. because cookies are
disabled), while encodeRedirectURL contains additional logic to
determine if it is desirable to write the session ID in. It is a
really bad idea to give foreign websites the session ID for example,
since then they could impersonate your user's session. Hence
encodeRedirectURL will only put the jsessionid on the URL if that URL
lies within the current Web application, and not perform any rewriting
otherwise.
Charles Lyons (SCJP 1.4, April 2003; SCJP 5, Dec 2006; SCWCD 1.4b, April 2004)
Author of OCEJWCD Study Companion for Oracle Exam 1Z0-899 (ISBN 0955160340)
also I found this answer too which was posted earlier,
posted 4/19/2006 8:02 AM Quote Report post to moderator Hi,
The encodeURL is used to encode the url for session tracking in
forward and include mechanism. The encodeRedirectURL encodes the
specified URL for use in the sendRedirect method.
The main difference between two is, the implementation of
encodeRedirectURL method includes the logic to determine whether the
session ID needs to be encoded in the URL in the case when you are
redirecting the URL to different context where the session information
is not required or invalid. The encodeURL method do not appent the
seesion id if the cookies are enabled. In addition to this
encodeRedirectURL do not append the session information if the URL is
redirected to the different context (web application). Because the
rules for making this determination can differ from those used to
decide whether to encode a normal link, this method is separete from
the encodeURL method.
Hope this help you.
Thanks
Narendra Dhande
encodeURL() is used for all URLs in a servlet's output.
It helps session ids to be encoded with the URL.
encodeRedirectURL() is used with res.sendRedirect only. It is also used for encoding session ids with URL but only while redirecting.
Related
How specifically is the state parameter related to the _csrf token in Spring OAuth2? Is state an encrypted version of _csrf as we would expect it to be?
Also, what specific Java syntax should be used to encode and encrypt a new _csrf value before encapsulating it into a new state parameter in Spring OAuth2?
THE CONTEXT
A client app redirects the user's web browser from the client app to the authorization server's authserver/login page. Then, in the authorization server app, a custom implementation of OncePerRequestFilter is used to redirect a request to /oauth/authorize?(list of params) into additional authentication steps, which ultimately redirect back into a new request to /oauth/authorize?(list of params). The problem is that the _csrf token changes during the additional authentication steps, and the documentation indicates that _csrf is used as the state parameter. This implies that the state value probably needs to be updated by the authorization server to reflect the new _csrf value.
HOW state IS GENERATED
The problem is that the encoded and encrypted value for state has already been set by the client app before the client app uses an OAuth2ClientAuthenticationProcessingFilter to transfer information for the authentication server to use while authenticating the user via the authentication steps mentioned above.
Some research indicates that the state key is generated by the client using a DefaultStateKeyGenerator, which in turn uses a RandomValueStringGenrator to generate a 6 character state value.
For example, in the original request made to /oauth/authorize?(list of params), the raw _csrf value is encoded into fupS1L, as shown in the following url:
/oauth/authorize?client_id=acme&redirect_uri=http://localhost:8080/login&response_type=code&state=fupS1L
If the _csrf value changes to a69fd23a-a393-4b27-a685-a323fd31db9a during the redirect flow, the value of fupS1L in the state parameter will no longer be valid, and the resulting token will not be authorized to permit access to protected resources.
What specific syntax do I use in order to convert the new _csrf value into an encrypted value similar to fupS1L that can be passed into a functional state parameter?
Also, is there any relationship between the state variable and the _csrf token? The RandomValueStringGenerator used by DefaultStateKeyGenerator seems to simply create a random 6 character String. I would like an authoritative answer by someone who has worked deeply with the code or even written it. I am doing a deep review of the code, so a casual passer by who reads the RandomValueStringGenerator source code and says state is not related to the csrf token would not be adding any value. The author of the API, however, would help us all out a lot by telling us how this works.
NOTE TO SPRING
It should not require this much digging to find documentation of such a simple thing.
I know it's quite old since its been asked. Still sharing what I know now, as I have worked through a similar requirement to pass a deeplink in the 'state' parameter. I wanted to redirect to this deeplink when flow comes back from the auth-server after a successful oauth sign-in session.
Primarily I followed this SOF answer -> https://stackoverflow.com/a/52462787/5107365. This suggests to extend the DefaultStateKeyGenerator to use the deeplink parameter from the request to AAS to encrypt+encode to set into the 'state' parameter. And, then the custom implementation of OAuth2ClientAuthenticationProcessingFilter.AuthenticationSuccessHandler is used to override determineTargetUrl method to decode+decrypt the state parameter when the flow comes back after successful auth. Hopefully it will help somebody who is in need of a similar requirement.
Reading below link , I could note that "doGet() allows bookmarks".
http://www.developersbook.com/servlets/interview-questions/servlets-interview-questions-faqs.php : search "It allows bookmarks"
Can anyone tell how and what is the use of it ?
All the parameters of GET request are contained in the url so when you are requesting for a resource using GET request, it can be formed using request URL itself.
Consider an example www.somesite.com.somePage.jsp. This generates a GET request because we are asking for a resource somePage.jsp.
If you are asking for a resource, then it is the GET request.
GET requests are used to retrieve data.
any GET request calls the doGet() method of servlet
GET requests are idempotent, i.e. calling the same resource again and again do not cause any side effects to the resources.
Hence, a GET request can have bookmarks
EDIT :-
As suggested by Jerry Andrews, POST methods do not have the query data unlike GET requests to form the resource properly with the help of only url. Hence they are not bookmarked.
It means that If you bookmark the URL of the servlet that has doGet() implemented, you could always get the same page again when you re-visit. This is very common when you have searches, link for products, news, etc.
we have a bunch of 'cflocation' tags in our cfmx apps, which lead to the session identifiers getting appended to the url.
Our main concern here is to remove the jsessionid, cfid and cftoken from the url for security measures.
We have tried the following and none of them worked for us:
1. 'addtoken=no' with the cflocation tag
2. tried using cfheader instead of cflocation.
How do we remove the session identifiers from the url?
thanks guys for the prompt answers!
I will try to answer the queries here
I tried replacing cflocation completely with cfheader like so
<cfheader statuscode="302" statustext="Temporarily Moved"/>
<cfheader name="Location" value="destinationURL"/>
We are using cookies to store session info. I am able to see the CFID, CFTOKEN, JSESSIONID cookies successfully being created on the users machine
Mitrah - If i set the 'setclientcookie' value to false, wouldn't that default to URL? Or am i not reading this correctly?
Do i need to tweak the 'cfapplication' tag in someway to make this work
It sounds like you are not using cookies to store your session, but are probably using client variables. If you are using client variables, then CF will automatically put the session tokens in the URL no matter what. This doc explains why.
Try to set setclientcookie = "false" in your application tag.
I've seen the existing question: Difference between encodeURL and encodeRedirectURL. But it doesn't answer the question really. In my testing, these two methods look like to do the same. Whatever I use to print or sendRedirect, they both work fine.
So is there really any difference? I want to see the source code so maybe I can find the difference, but HttpServletResponse is an interface with no implementation. Where is the implementation code?
but HttpServletResponse is an interface with no implementation. Where is the implementation code?
It's the servletcontainer itself which is the concrete Servlet API implementation. In case of for example Apache Tomcat the concrete implementation is the org.apache.catalina.connector.Response. Here are the extracts of relevance:
1128 /**
1129 * Encode the session identifier associated with this response
1130 * into the specified redirect URL, if necessary.
1131 *
1132 * #param url URL to be encoded
1133 */
1134 public String encodeRedirectURL(String url) {
1135
1136 if (isEncodeable(toAbsolute(url))) {
1137 return (toEncoded(url, request.getSessionInternal().getIdInternal()));
1138 } else {
1139 return (url);
1140 }
1141
1142 }
1159 /**
1160 * Encode the session identifier associated with this response
1161 * into the specified URL, if necessary.
1162 *
1163 * #param url URL to be encoded
1164 */
1165 public String encodeURL(String url) {
1166
1167 String absolute = toAbsolute(url);
1168 if (isEncodeable(absolute)) {
1169 // W3c spec clearly said
1170 if (url.equalsIgnoreCase("")){
1171 url = absolute;
1172 }
1173 return (toEncoded(url, request.getSessionInternal().getIdInternal()));
1174 } else {
1175 return (url);
1176 }
1177
1178 }
The difference is very subtle. The encodeURL() uses the full absolute URL whenever the given (relative) URL is empty.
Those two methods can only produce different results when your application container uses URL parameters to communicate the session ID. Since almost everyone uses Cookies to do this these day, it's unlikely that you will see a difference in your normal testing.
To force session IDs in URLs, either deactivate storing session cookies in your browser (and hope that your application server detects that fact) or explicitly enable session IDs in URLs in your application server.
I looked and looked for an answer I knew I would find it in either stackoverflow or coderanch and there I found the answer from Charles Lyons the author of the book in my hand right now it was a cheerful coincidence.
posted 8/9/2008 11:41 AM
Exactly - the difference being that encodeURL always writes the
session ID into the URL (if required e.g. because cookies are
disabled), while encodeRedirectURL contains additional logic to
determine if it is desirable to write the session ID in. It is a
really bad idea to give foreign websites the session ID for example,
since then they could impersonate your user's session. Hence
encodeRedirectURL will only put the jsessionid on the URL if that URL
lies within the current Web application, and not perform any rewriting
otherwise.
Charles Lyons (SCJP 1.4, April 2003; SCJP 5, Dec 2006; SCWCD 1.4b, April 2004)
Author of OCEJWCD Study Companion for Oracle Exam 1Z0-899 (ISBN 0955160340)
also I found this answer too which was posted earlier,
posted 4/19/2006 8:02 AM Quote Report post to moderator Hi,
The encodeURL is used to encode the url for session tracking in
forward and include mechanism. The encodeRedirectURL encodes the
specified URL for use in the sendRedirect method.
The main difference between two is, the implementation of
encodeRedirectURL method includes the logic to determine whether the
session ID needs to be encoded in the URL in the case when you are
redirecting the URL to different context where the session information
is not required or invalid. The encodeURL method do not appent the
seesion id if the cookies are enabled. In addition to this
encodeRedirectURL do not append the session information if the URL is
redirected to the different context (web application). Because the
rules for making this determination can differ from those used to
decide whether to encode a normal link, this method is separete from
the encodeURL method.
Hope this help you.
Thanks
Narendra Dhande
I wants to know that How can i Manage Session if the client browser has disabled cookie feature..
If I wants to implement it in simple JSP - Servlet, then how can I do that ?
Thanks in advance...
Without cookies, you have two options. The first is passing a sessionId through Urls. This requires a lot of work on the server because every url you send back must have a sessionId appended to it (usually in the form of a query string parameter). For example:
/path/to/page
becomes
/path/to/page?sessionid=ASDFG-ASDFG-ASDFG-ASDFG-ASDFG
The other option you have would be to combine what information you have via http into a "unique" key and create your own session bucket. By combining the Http UserAgent, RemoteIp and RemoteXfip you can get close to uniquely identifying a user, but there is no guarantees that this key is 100% unique.
In the JSP side, you can use JSTL's <c:url> for this.
link
Easy as that. It will automagically append the jsessionid when cookies are disabled.
In the Servlet side you need HttpServletResponse#encodeURL() or -usually the preferred one inside Servlets- HttpServletResponse#encodeRedirectURL() for this.
response.sendRedirect(response.encodeRedirectURL("page.jsp"));
url rewriting
http://www.developertutorials.com/tutorials/java/implement-session-tracking-050611/page5.html
Each URL must be encoded using response.encodeURL("page.jsp")
This will add the Session ID onto the end of each URL so cookies do not have to be enabled.
Note that you will have to do this manually for every single URL in order for it to work.
See this link for more info.