URl Switching between subdomain - java

I have site say http://info.sys.com
I want the info in the url to be replaced to knowledge.sys.com when i select knowledge tab in my website.
info.sys.com should be replaced to knowledge.sys.com when i select knowledge tab.
I use jdk 1.5 update 9 and tomcat 6.0.16
Looking forward for your reply.

If you change the URL (location.href = 'http://knowledge.sys.com';), the page will be reloaded -- well, actually, the page at that address will be loaded (whether that's the same page or not will depend on your server).
There are games you can play with anchors, though (the "hash" part of the location). Check out Really Simple History for more on that.

Changing the URL field programmatically on the client-side will trigger the browser to refresh the page with the updated URL.
This is considered a security feature which guarantees that the URL field is always showing the address of the rendered resource.
You can use a URL Rewriting Engine on your server if you cannot host your knowledge base at knowledge.sys.com. This could be configured to handle requests to knowledge.sys.com without having to change your application file structure.

Related

What is the best solution for lost JSESSIONID cookie on Java Web App Redirect?

The Problem
When redirecting from a servlet using response.sendRedirect(redirect_url);, the JSESSIONID cookie is not passed by the browser to the destination. A new JSESSIONID is created for every redirect, and it is impossible to track the user.
Note: This problem is only occurring on my new server implementing https and a domain name; the session ID is properly tracked when I run the web app locally or on another server without SSL or a domain name. Edit: I have set up another site on my server without SSL, and the issue persists. This seems to narrow the issue down to having a reverse proxy Apache.
An Example
The Login servlet on my web app attempts to store the user information in a session attribute then redirects to the MyCards servlet. I am using a redirect so that the URL will display mydomain.com/MyCards instead of mydomain.com/Login. The MyCards servlet attemtps to access the session attribute but finds nothing, and therefore redirects back to the Login servlet. This worked perfectly before deploying the project on my new server with SSL and domain name.
My Setup
Ubuntu 20.04 on DigitalOcean droplet
Apache Web Server (apache2) ... I have enabled mod_sessions, not sure if that's relevant.
Tomcat 9
Reverse proxy in Apache VirtualHost to Tomcat (I can post my .conf file if requested)
A redirect in Apache VirtualHost from HTTP to HTTPS
JDK 11
Possible Solutions
Using a forward instead of a redirect. The session ID is not lost when using requestDispatcher.forward(request, response);. As I mentioned above, I want the URL to reflect the destination for an intuitive user experience, which does not occur when using a forward.
Implementing your own session cookie, as in this answer, and manually storing sessions with a map, as in this answer, which strongly advises against such a facility. Based on my understanding, doing so poses security threats to user data. Also, if the browser is not passing the JSESSIONID cookie, I don't understand why it would choose to pass the manually implemented cookie unless the SameSite attribute is set to None (also bad).
Verifying that the webapp's context.xml does not have cookies="false" configured. Done that.
Using encoded URLs with response.sendRedirect(response.encodeRedirectURL(url));. Again, for the sake of having a clean URL (which the user could bookmark or type in) is preferable, and encoding the session ID into the URL is not.
Using relative URLs instead of absolute URLs...
"A session is only maintained if the redirection is being sent on the same port, host and webapp [and protocol?]. If redirection is done within the same application, using relative paths is the best practice." I tried both redirect_url = "/MyCards" and redirect_url = "MyCards", no luck.
Possible Reasons
Perhaps I am unknowingly switching between HTTP and HTTPS, which is a change in protocol and will not preserve the session ID. Of course, my intention is to remain secure and stay exclusively in HTTPS. Edit: I have set up another site on my server without SSL, and the issue persists. This seems to narrow the issue down to having a reverse proxy Apache. When accessing the web app directly on Tomcat (i.e. with <server_ip>:8080/MyWebApp), the session is tracked properly on redirect. However when using mydomain.com, the session ID is lost on every redirect.
Something to do with naked domains.
Other?
Edit: Maybe the issue is occurring because of the way the client, Apache, and Tomcat interact via the reverse proxy. Does the proxy cause the domain/port to change on every request/response?
My Questions
Why exactly is the session ID lost when using a redirect to a relative URL to a servlet in the same web app on the same server? Shouldn't the redirect occur entirely on the server-side, preventing a new request/session from being created? Since the relative URLs (which I thought would preserve the session) did not solve the issue, does this indicate some problem with my server setup (e.g. unintentional switching between protocols)?
What is the best practice for maintaining the user session ID, even when the user has cookies disabled? Is there no way around URL encoding when cookies are disabled? Or should the app be implemented exclusively with forwards rather than redirects? If so, is there a workaround to changing the URL to reflect the destination?
Note: this is my first post, so I don't have the reputation to comment. I will edit the post with any needed information.

In Safari, the session are not maintained between subsequent POST and GET

i have an application running on Tomcat 7.0.27 which is our organization network and second application which is running on Amazon Web services( which is nothing but Tomcat 7.0.42). The application that is running on amazon is inside the iframe of the first application. The application running on the Amazon is self contained i.e all the files that it needs resides inside of the same tomcat container and don't communicate with the first application.I see that entire site works fine in FireFox and chrome. But having problems in safari. In Safari the launch of the second application is Successful( which is nothing but a POST) but the subsequent Request( which is GET) fails. So in code what we are doing is that after the POST we are putting a Java Object in the session like this
SessionData result = new SessionData(request,oauthCredentials);
request.getSession().setAttribute(SESSION_ATTR_TC_DATA, result);
So after the POST the first request that come is GET, when this request come in we try to get the Java object that we put in the session like below.
SessionData result = (SessionData) request.getSession().getAttribute(SESSION_ATTR_TC_DATA);
request.setAttribute(SESSION_ATTR_TC_DATA, result);
But in Safari i see that the session id(JSESSIONID) in POST is different From that in GET and the soSessionData=null; I see that the Session Id is same in case of FIREFOX/CHROME.
I see that from a URL/IPAddress
http://one.roses.flowers.org/ #IpAddress=141.21.19.87
http://test-dev.elasticbeanstalk.com/ #IpAddress=64.261.831.97
I am not creating any sessions by writing the code. Tomcat is handling it.
But this Whole Thing work across all the browsers when the First tomcat/second tomcat running inside our organization Network. I see that from a URL/IPAddress
http://one.roses.flowers.org/ #IpAddress=141.21.19.87
http://five.oranges.flowers.org/ #IpAddress=141.21.19.88
Why would Safari behaves indifferently in this case?
What made it work in Safari is by turning off cookie restriction to accept from Third party. Same is true for the IE as well.The default setting is not to acccept 3rd party cookie. For FF/Chrome the default option is to accept 3rd party cookies.
I have used Webscarab tool to debug this issue.
The application that was inside of the iframe was on AmazonWebservices the URL pattern was totally different from the origination Site. so that made browser think that these calls are made from/to some external site. So based on the Browser cookie setting the browser severed up the Application inside of the iframe.
Also, the 2 URL look like this to the browser.
http://one.roses.flowers.org/
http://test-dev.elasticbeanstalk.com/
We added the Alias/cname to the project on the AmazonWebservice(AWS) server in the higher environment(QA/PROD) something shown below. By adding alias to the url browser don't consider the URL coming from 3rd party as both has same domain name. Now the solution is independent of the browser cookie settings.
http://test-dev.elasticbeanstalk.com/ ---> http://aws.newsite.flowers.org

response.sendRedirect to a file URL from Chrome

I have a URL shortener app (similar to tinyurl.com, bit.ly etc) which redirects to file:// URLs as well.
Internally, this is a Servlet based web-app, and all I do is, retrieve the targetURL and do a response.sendRedirect(targetURL) from the server side.
This works fine for file:// URLs too. However, recently, this has stopped working on Chrome. When I try to redirect to file://foo.txt (via a response.sendRedirect('file://foo.txt'), things simply fail (the Chrome debugger says "Cancelled").
Things work fine in FF and IE however. Any clues ?
I'd say this is a bad idea, and I'm glad at least chrome denies this (although I would suspect that other browsers would as well). It would be a pretty big security hole if you could instruct someone else's browser to open an arbitrary file.
Second, why would you want to do this? It would require that the user actually have this same file, at the same location on their computer. Seems like a pretty narrow use case. I tested your use case with bit.ly, and it you try to add a file:/// url there, it's regarded as an invalid URL and cannot be shortned.
Edit: There's a very good answer covering the same topic here. It references this useful resource about security restrictions with redirection.
You also specify that this is for an internal app. If you're attempting to do some sort of document sharing, I'd say you should look into dedicated systems for this. Another option is to extend your service with a "dropbox light", where your users can upload the file in question to a storage service, and you can generate a shortned url based on serving the file from your storage via regular http/https.

Setting HTTP_REFERER for URLS on webpages?

I have a webpage which refers other pages.
I want to be able to set the HTTP_REFERER on the URL's that are clicked.
What options do I have?
What options do I have?
None really. The browser sets this automatically.
The only thing you can do is redirect to a script (under your control) like
http://example.com/redirect.php?url=........
That file (in this case, PHP) would then do a header redirect to the target, and show up in the receiving site's HTTP_REFERER header.
Also, linking to a https:// page from a http:// one or vice versa will drop the referrer. See the Wikipedia article on referrer hiding.
Other than that, there is nothing you can do to alter it. There is definitely no way to set it to an arbitrary value from within a web site.

Is there any way to have an applet clear its own cache programmatically?

My applet currently accesses a url and prints the contents at that url. The problem is that url is fixed, but that url renders something different depending on the website's state. My applet will print a cached version of the contents at the url instead of actually retrieving the new one. I don't want the user to have to restart their browser just to get this applet to work properly and the separate_jvm tag only helps if the user refreshes the page. If I manually go into the java console and clear the classloader cache that seems to make it work.
Pretty much I want to be able to programmatically clear a JVM's cache.
After careful searching I haven not been able to find a solution, but, I was able to remember of the classic timestamp solution. If I append the timestamp to the url, even if it's not used, it will never have a cache problem.
What you need to do is set the HTTP 1.1 Cache-Control request header to no-cache. How you do that depends on the library you are using. If you are using the Apache HTTP Client, take a look at HttpRequest.setHeader(). Changing the timestamp works, but tends to clog caches with stuff that can't be reused.

Categories