I have a Java App Engine app and whenever we modify any classes that are serialized as part of the session anyone that had a pre-existing session is broken (since the object persisted or in memcache is no longer compatible with the new object). I've done a bunch of searching and it seems as though there's no way to get those users working again unless they clear their cookies or we clear every entry in _ah_SESSION. The error happens so high up that the browser is sent a blank page, so we can't even do something like returning a page that can delete the cookies with javascript. I've tried creating a servlet filter, but the error happens before any filters are processed.
This appears to be a pretty wide-spread problem - I can't believe there's no way to handle this.
Thanks,
Stephen
Related
In my websphere console session properties, the url rewrite is not enabled and I am 100% sure that I dont have any JSESSION suffix or anything on my jsp pages to generate and append the JSESSION. But the issue is on some specific pages like everything which its URI is xxRead.do. The JSESSION is appended at the end of URI automatically and I am not able to prevent it from happening.
Can anyone help me out here, thanks,
JSESSIONID is what is used to keep track of a users HTTP session.
It's absolutely necessary for any web application that will maintain a user session.
As far as I know URL rewriting will only be used by any reasonable web server only as a fallback if cookies are disabled.
Please make sure that's not the case.
In a webapp I'm using several filters and in one of the filter I'm using something that BalusC described as "session abuse". Basically in the Filter I do something like this:
request.getSession().setAttribute("abuse", ...);
while, later on, in a Servlet, I read back this attribute.
I'm using a session attribute instead a request attribute because I'm doing a redirect and that's where I'm lost...
After the browser receives the 302 and does the redirection, how does Tomcat (or any other Java webapp server) knows that the subsequent GET (the one after the redirect) belongs to the same "session" as the session returned while inside the first Filter (the one before the redirection took place)?
Does this work even if the client's browser has both JavaScript and Cookies turned off AND if I'm disabling JSESSIONID?
I should point out that JSESSIONID is disabled for SEO and for user-friendliness purposes: just like stackoverflow.com does never show super long URLs with pointless technobabbles in them, my webapp doesn't either while JavaScript and Cookies could be turned off by the user. So I want to know if the "session abuse" I'm doing would be working even if these three "client-side features" are not available.
If you have cookies disabled and url rewriting disabled, then the Servlet container cannot track sessions. Actually I think a few still can using SSL - there's a session tracking built into SSL, but I am not sure many servlet containers support this methodology and it requires pure SSL.
If you don't track sessions, then each session gets created and then orphaned.
I just want to ask how do I make sure a user is still logged in. If he/she's not, then access to pages is not permissible. See, when logging in a page I use a filter to check if the user exists. I wonder if I could use filters to check if the user is still logged in? Only problem is, I tried but when I type the url directly on the address bar the page still shows, now with null values. How does one do this correctly in Java?
What web framework are you using?
Yes, it is achievable using filters/interceptors in most scenarios, especially plain vanilla web applications. In your case, you most likely did not nullify/invalidate the invalid user, or have not redirected invalid users to another page (login page for example).
If you are using Struts, or Spring, i would highly recommend you looking in the direction of Spring Security (Former ACEGI) or Apache Shiro because chances are although your home-made solution would appear workable, they are not spoof proof.
Set a session variable, isLoggedIn=true, after the user logs in. In the filter, check if the session is null, or the logged in flag is false. If not, redirect to some page saying you must login to continue.
Anyone ever tried the following? (and was successful)
In a web application (A), I am using the <c:import> tag to get secured content from another web application (B) running on the same application server (WebSphere 7). Both apps use Hibernate and Spring's OSIV filter.
Looking at the import tag source, I see that the strategy is that if the url is relative then it includes the content using RequestDispatcher.include() .If the url is absolute, the code opens a URLConnection.
Since I need to keep track of the remote user, I can't do the following:
<c:import url="http://host:port/B/getContent">
Doing
<c:import url="/getContent" context="/B">
instead would work. But with this approach I am not hitting Spring's OSIV filter configured in B. The original (importing) request in A does go through the OSIV filter but it has no effect in B. Hence I am getting the usual "No session or session closed" error for lazy initializations of entities.
I am bit in a catch 22 here and I am wondering if what I am trying to do is actually feasable according to my requirements.
The bottom line is that I did manage to get what I wanted by aggregating my content directly from the client using Dojo, (I am using SSO so the identity of the user gets carried) but I would prefer the other way if it was possible.
We have a web-based application with tech stack -
1. Java Struts based
2. Hibernate
3. DB - Oracle
4. App server - JBoss server
We are facing an issue related to concurrent usage of the application by two or more users. When I am doing an operation and I submit the changes, the next page or success message that comes up is of a different operation that another user is performing at the same time.
Users are logged in as different users and so are using different sessions.
We have no clue of where the problem is, so I am not sure what other details I can provide.
Has anyone else faced such an issue or any pointers?
Are you using application context instead of session context? Moreover, as Eed3si9n said, beware of Singletons, that might be causing this.
"In addition check for the use of static fields. One app I was brought in to fix used a static string for error message. As soon as any user received an error they all did. Worked fine until there wasmore than one concurrent user." – Michael Rutherfurd (posted it as a comment)
I am not familiar with specific libraries you are using, but let me try.
How stateless are your application code? Do you have any sort of global state like singleton with member fields? If the service is stateful and are using singleton, you could have such mixups.
Check if the form is defined as application scope and the message you showing on the screen is coming from that form.