One browser means one client but what if two browser from same machine?
I think it should be considered as one client because I see the similar session id for any no. of browser. Anyway keeping these things in mind, I have an issue.
A client send file and server's application create a unique folder in context to save file.
unique folder : it is auto created & for each client.
so my question is, is session id perfect solution for unique folder name ??
#Edit : An application upload multiple files in a auto-created folder from client to server and provide a link to download the same folder to same client.once the client downloads the folder(all files), it is removed otherwise remains for next couple of hours(programmed).
what if there are many clients uploading the file, then how should I avoid the duplicate folder name? So I thought to autocreate folder on the basis of session-id
Using the session id will give you one folder per session.
How the client relates to sessions depends on several things: usually, different browsers (ff, ie, etc) do not share sessions, so each new browser will have it's own session with your server - irrespective of the machine on which the browser is running. If the user opens multiple windows using the same browser, they will share the same session if using cookies, but have different sessions if the sessionId is embedded in the url.
Edit: if the sessionId is in the URL, you can in fact get any browser on any machine to share the same session by copying the URL, with the sessionId, into the browser.
Yes session id seems to be fine.
Session_id can indeed be duplicated, but the probability is very low.
If you have a website with a fair traffic, it may happens once in you
web site life, and will just annoy one user for one session.
This is not worth to care about unless you expect to build a very high
traffic website or a service for the bank industry.
-> How unique is the php session id
don't you have an authentication system? if users get logged in, user id is the one you need to use. so, even if two different users logged in from the same machine, they will have two seperate folders. if you don't require authentication, maybe you can force to get a new session id for the first connection.
Related
I have java web application using struts 1.x. Recently my application has gone through penetration testing and our testers found some security holes. Let me explain. In my application i have 2 users called ‘Admin’ and ‘user’. First our PenTester logged to my application as ‘Admin’ and they use ‘Burp tool’ to intercept the request and copy the whole request content into notepad and then forward the request. Now My application log in as ‘Admin’. They use another browser instance to login as “user” and use burp tool to intercept the request. This time they removed the whole request content and copy back the whole request content of ‘Admin’ and then forward the request. Now my application logged in as ‘Admin’ without asking any user id/password? How to restrict this situation? I already stored userid in my session variable after successful login of each user. The moment they intercept the request and copy the ‘admin’ request content, my session variable userid also changed to ‘admin’. How to validate this situation? Your help is really appreciated.
That is not really that much of an issue since the first part "copy the whole request content" is not easily doable if you have a proper HTTPS / SSL connection. That only works if the PC the user is logged in on as an admin is compromised in which case: nothing you can do about it anyway because they can just sniff the keystrokes and get the plain password.
If on the other hand you communicate without the S, namely just HTTP then the solution is: get a certificate and switch to HTTPS.
Apart from that your application can pin a session to an IP which means if the session id / cookie is stolen and someone else uses it you can detect an IP mismatch and ask for credentials again.
To prevent direct replay attacks like copying the request and sending it again you can introduce a hash that incorporates the timestamp or alternative measures, see. How do I prevent replay attacks? . The problem however is that copying the entire request means copying the cookies as well and if the "admin" cookie is copied this measure will not prevent you from "generating" a new hash based on the now admin user.
I have a website under a domain called www.example.com.br. And my server is set to work with cookie session tracking mode.
getServletContext().getSessionCookieConfig().setDomain(".example.com.br");
getServletContext().getSessionCookieConfig().setPath("/");
But now I'm introducing an english version of the website under www.example.com, because for Google and SEO techniques it's better to have different domains instead of a subdomain.
I found a lot of questions in Stack Overflow about this, and I know it's impossible for a lot of security reasons.
But isn't there anyway to tell Tomcat to work with a cookie domain .example.com.br if the URL has .com.br and .example.com if the URL has .com? I don't need to share session information... ie: the user may have to login again if he changes the domain. I'm not worried about it. The problem is that no information on the .com version is been stored at all, because the cookie is set to .com.br version.
Isn't there any workaround for that?
It is user's browser that decides whether to send the cookie with the request or not. Web server (Tomcat, in your case) does not have any say in that decision. What you are asking for explicitly forbidden. For example, RFC2109 says:
A user agent should make every attempt to prevent the sharing of
session information between hosts that are in different domains.
The best recommendation I can make is to make your session management (login, logout, ...) work off a single domain, regardless of what domain user originally accessed.
We are facing one issue in a Struts application deployed in JBOSS clustered environment with load balancer and sticky session
Issue description
1) This issue happens in a user registration functionality which has 2 pages, register1.do and register2.do page
2) When user clicks on registration url, https://ourwebsite.com/register1.do
Two GET request are made
GET register1.do (Gets 1st registration page and sets few values in session)
GET captcha.do (This loads a captcha image to be shown on register1.do)
3) Sometimes what happens is GET request to register1.do sets a JSESSIONID cookie and the GET request to captcha.do over write JSESSIONID cookie set by first request. This causes problem in 2nd registration page as it fetches some of the values stored in session and as the session is overwritten by captcha no values can be obtained.
see below image
4) This scenario does not happen every time, once this issue occurs and if we go back to register1.do page a refresh(F5)/hard refresh (Ctrl + F5) then GET request to captcha.do does not over write JSESSIONID cookie and user registration works fine.
Moreover this happens only in clustered environment, in single JBOSS environment it works fine.
Can anyone please help me to identify what could be possible problem
here ?
Why session does not get over written when we do a page refresh ?
Update your apache mod_cluster binaries to mod_cluster 1.2.6.Final which are available here.
This solved it for me, which was jumping servers after every single refresh. Hopefully that helps.
I also experienced the same problem with jboss eap 6.1 and in load balancer i'm going with mod_cluster configuration I changed algorithm from server per session to entry per session and sticky session is working well and good .Go through the following to know about entry per session and server per session.
Entry-per-Session means that the device creates additional client-table entries whenever a source IP opens a new session (unique source port). This gives the unit more accurate tracking of the number of sessions, but it's behavior is to continue sending all the traffic from the client's source IP to the same server.
In Server-per-Session mode, the device tracks the unique source ports the same way, but when the client opens a new session, the device makes a new load-balancing decision for the new session. This way multiple sessions from the same client IP can be 'sprayed' among all the servers rather than being stuck to a single server.
What would be good/scalable user session alternative in following scenario:
users don't have to have cookies enabled
URL query string restriction of 255 characters is imposed
lot of GET requests (no hidden form fields)
application runs on several servers (web farm)
some users connect over proxy (same IP)
users connect over HTTPS
50 000 concurrent users
If you can guarantee that the client always connects to the same web server, you can use the SSL ID as a simple session tracking mechanism. Some web servers expose this capability and automatically use it for session tracking when cookies aren't supported.
The only solution that will work no matter what is to include a session ID in the URL itself. Adding a parameter to the URL is the simplest way to do this, but the ID can be embedded anywhere in the URL, i.e. as part of the path. You would use this ID to fish information about the user out of a database.
You will run into the usual problems, of course, with ID spoofing and having the session database be a bottleneck.
First, IMHO, there is no good alternative to session. The question is how do you obtain it when cookies are disabled. The answer is using URL parameter. So, you have to append session id to each request (including links and forms). All other requirements are not really relevant. Make your logic stateless, so you do not have scalability problems: all requests should arrive to your logic via load ballancer, so you can add as many servers as you want.
Maybe URL Rewriting or some URI shortening mechanism like http://tinyurl.com or http://goo.gl so you can pass your session details well under 255 chars.
Note: Not recommending to use these services but the mechanism.
First of all, your requirements are very tight.
The only option I see is using an approach like this: http://code.google.com/p/seaside/
In short: your system will generate statless urls like
http://host/app/#123445568978
Then you will go on the db to get the session object.
50000 users doing what? Continuous drag-and-drop with position updates to the server or clicking a text link every 15 minutes? In the last case: move everything onto a single server with a lot of ram.
In my Java EE application, I have a problem with sessions. Different users can login to the application and the specified user can see the data for which he is authorized. He should not be able to see other user data. To differentiate users, we are using Client_ID. As soon as the user logs in we are fetching this Client_ID from the database and setting it in session like this:
session.setAttribute("Client_ID",user.getClient_ID())
We access this session value throughout the application and fetching the relevant data to that Client_ID. This works fine when users work on a single browser, but the problem is this:
Suppose there is a SuperAdmin, who needs to look all the clients under him. SuperAdmin logs in as client_1, and again as client_2. SuperAdmin has logged in both times using the same browser. When I refresh the client_1 browser, I am seeing the client_2 details, which should not happen.
I think our application is using the same session for two different logins in the same browser. What would be solution for this problem? I should see the correct data for the particular client when I refresh the page.
Don't use cookies for storing Session ID, but use request parameter instead.
So each opened tab will request the own session. With cookies you have only one cookie for all tabs in browser.
P.S.:
I think that it's incorrect to log in under 2 or more users within one browser at the same moment. Your application should detect that client_1 is already signed it and restict log in for other users from the same browser until logout. For example, Google's applications work in such way.
Also would be great if SuperAdmin have a feature to see client_1 or client_2 data without log in. This will save him/her from remembering dozens of passwords and will increase performance of work (time is moneys, isn't?).
If you want multiple tabs within the same browser instance to see different things, then you will have to rework your session management and key things off of the URL.
The session is shared between browser tabs (true for most browsers), so logging in with one tab will affect the sessions for other tabs.
The solution is to use roles instead of multiple logins. You would give client_1 SuperAdmin role, and client 2 doesn't. This would reduce the need to login twice.
But in any case, you should only allow one user to be logged in at once. The process of logging in should invalidate the previous session. I forget the exact code in Java EE, but it is something like session.invalidate().