I'm using Spring MVC, MySql and Tomcat 7.
Currently the application I'm developing can be accessed by 2 URLs namely IP:PORT/APP and www.app.com.
When accessing via www.app.com I see a session being created for every page/link that I open but it doesn't happen when I access via IP:PORT/APP.
I have a check for logged-in user in every page and due to too many sessions that check is failing and I'm being re-directed to my login page even after logging in.
Also when opening the www.app.com index page I see a jsessionid on the address bar and not when i open it via IP.
Any help/guidance is appreciated.
It seems that when you are accessing the page via domain name (www.app.com), cookie support is not found and hence the url rewriting is being done (i.e. appending jsessionid at the end of the url). But this is not observed while accessing the same page via IP Address (IP:PORT/APP), meaning cookie support is enabled at this time.
You can check if you have enabled some security settings that is not allowing cookies.
Further to this, it seems that even url rewriting is not helping as sessions are being created for every request.
You can use some HTTP Interceptors to analyze the request being sent and response being received in each case. You can use Developer Tool in Chrome to inspect this. Load you page in Google Chrome, Right Click on Page and Click 'Inspect Element'. Open the 'Network' tab. Reload the page. You can now inspect the HTTP Request Headers sent and Response Headers received for each request. Analyze the difference between the request using IP Address and requests using Domain Name.
Also, share the architecture of the application and the environment where you are testing the application.
Related
I was asked to implement a "one session per account" limitation on an old java 7/struts 1 web application.
During development, I'm getting a behavior which I can't really understand.
So if there's an account "Account-A" currently logged in with a session "Session-1234" and then the same account gets logged in but with a different session "Session-4567" then the session "Session-1234" is marked to be invalidated in the next request performed by that session.
During the process of invalidation of the "Session-1234", one of the steps is redirecting(302) the client to the login page.
Now is what I don't understand.
If the request is coming in "synchronous" mode, everything works as expected.
User clicks some link
Server -> invalidates session and redirects(302) login.
Browser -> detects 302 looks for Location header and performs a get.
Server -> serves the resource.
Browser -> show login and update the URL.
If the request is coming in "asynchronous" mode aka AJAX, now I have problems because what happens is that the page never changes and the content of the login is displayed right there.
My question is not how to solve this "problem", but rather have a really good grasp on why it behaves like this.
If you are working with a programmatic client, you have 2 main options:
Don't use cookies, use the Authorization header and let the server emit a 401, telling the client their token is now invalid.
With your javascript client, read if the server returned a 302 response and Location header and respond to that.
#2 is basically a hack that lets you mimic the standard browsers' behavior. #1 is more appropriate for an API.
I have a magic link to access a website without logging in, let's say the magic link is something like this
https://key.example.exampl.tr/auth/realms/test/protocol/openid-connect/auth?client_id=my-react-client&state=ba453a80-d991-4b3b-a791-3fc2629aea03&redirect_uri=https://test.example.exampl.tr/&scope=openid&response_type=code&user_id=d0bcdd07-3198-4ab6-9cfd-d0b6341dbe00&key=7a1b4163-76e8-465c-a914-c68f16761698
when I use the link in the browser it works as expected and accesses the home page without asking me to log in. BUT when I use the same link inside HTTP GET Request using JMeter, it redirects me to the login page. Why is that happening and how to solve it?
This is happening as you browser stores specific cookies and caches for the particular request, whereas for jmeter you will request a new session every time, if you are not using HTTP Cookie Manager and HTTP Cache Manager explicitly.
Try clearing your browser history, cookies & caches and hit the same request/url, it would also redriect to the login page and behave same as jmeter does
I am trying to do a load test using JMeter for the first Time.
My approach is to test each page one by one.
The main page is like http://localhost:8180/myapp/login.do?actionType=login(I hardcoded the credentials)
I am able to reach this page without any problem.
I created a HTTP request component and able to see the response without any issue.
In the main page there is a button which populates the report, in the browser , the url is like
http://localhost:8180/myapp/mainmenu.do
But when i create a HTTP request it is reaching but shows the security error page in the 'Response
Data' as Due to security reasons, we still recommend you to close this window.
can someone guide me how to test the other pages without these security errors. This is a struts2 Web application.
No matter what technology is being used under the hood of the web application you're testing you should stick to one simple rule:
Well-behaved JMeter test must send exactly the same requests as real browser
It includes:
Same number/sequence/nature of the HTTP Requests
Same HTTP Headers (including Cookies)
any dynamic values need to be properly correlated
Once JMeter will send the same requests as real browser does it should receive the same responses. So just use a 3rd-party sniffer tool like Fiddler or Wireshark to capture the requests originating from browser and JMeter and amend JMeter's configuration until the requests start looking exactly the same. This should resolve your issue.
Solved the issue by adding HTTP Cookie Manger and
set Cookie Policy as Standard
click HTTP Cookie Manager
and click save icon on the top.
Source
https://jmeter.apache.org/usermanual/build-web-test-plan.html#adding_cookie_support
Thanks #Dimitri T and #Roman C for their valuable suggestion.
Anytime a user tries to access our site with http, they are redirected to https via this code in the Application.cfc:
If (CGI.HTTPS != "on") {
location(url="https://#Application.PortalApp.GetDomain()##CGI.SCRIPT_NAME#?#CGI.QUERY_STRING#", addtoken="false");
}
The strange thing is, if they have never accessed the site via http, but happen to click an internal link that points to http instead of https, they are logged out. However, once they login again, they can then access an http link, get redirected to https and stay logged into the system.
I did some line-by-line debugging and the https session gets overwritten when a user access http. But once a user accesses http, the https shares the sessionid.
Is this correct behavior?
In ColdFusion Administrator Session settings, HTTPOnly is set to true, and secure cookie is set to false.
Think of them as two completely separate domains.
The session under HTTPS is a completely different session from the one under HTTP. That's just how that works.
Instead of controlling it at the application code level, you should configure your web server to only allow connections over HTTPS and automatically redirect HTTP requests to HTTPS.
Here's a link for IIS.
Here's a link for Apache.
More info can be found in this Google Developer page, but I'll paste the highlights.
HTTPS protects the integrity of your website
HTTPS helps prevent intruders from tampering with the communications between your websites and your users’ browsers. Intruders include intentionally malicious attackers, and legitimate but intrusive companies, such as ISPs or hotels that inject ads into pages.
HTTPS protects the privacy and security of your users
HTTPS prevents intruders from being able to passively listen in on the communications between your websites and your users.
You'll want to make sure that internal links on your site are never explicitly using HTTPS, so look into setting <base href="https://{yourDomain}" > in your layout files to force all relative URLs to use HTTPS.
I've been having the same problem and this fixed it.
On Server2008, in IIS Manager, open up the ASP properties, expand "session properties", and change "New ID On Secure Connection" to "false".
A couple suggestions:
Easy one first: this may not be the right direction, but what happens if, instead of using CGI.HTTPS, you use CGI.SERVER_PORT_SECURE?
If CF is overwriting the session when you switch from https to http, why not just handle this on the front end with the web server rather than through CF? IIS and Apache all have easy rewrites or redirects that may save you some time over trying to deal with CF, particularly if your whole application is secure anyway.
It seems that the check for user being logged in is before the http to https check and redirect. If possible you should check for https first (redirect if is http) then check for logged in.
I have a form based authentication application I am able to log on the system as per my database by posting a request on my log in page.
But after that if try a get request of any internal pages I get a request as www.example\login?dashboard with a cookie but the response html is of my login page.
I have a cookie manager added on the top.
There are a couple things to check that could be causing this:
There is a hardcoded parameter, like sessionID that needs to be unique for each session
The page requests have "automatic redirect" enabled and should not (or vice-versa)
Login is actually failing, but the site is not giving a clear error message