Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
I have a problem with Bonita that I've tried to work around without success. I am authenticating with CAS into Bonita, Alfresco and Liferay; the first time I am authenticating with CAS everything works fine, but when I logout from Liferay (which should then logout automatically from CAS), the current Bonita session is not terminated. The next time I login with CAS the Liferay and Alfresco sessions are correct (they belong to the new user), but the Bonita session doesn't change (the old user is still connected). Did anyone encounter this issue, and if yes, what could be a possible correction for this?
Any insight regarding the matter would be very appreciated, thanks!
I have managed to do this after a couple of difficult attempts to understand what the problem is. Apparently, there was a problem with the session cookie created by Bonita: the cookie JSESSIONID with the path "/bonita" was not destroyed when CAS destroyed its session and somehow its presence stopped it from being recreated. I have changed the Bonita cookie name to be different than JSESSIONID, because there were other cookies with that name in the browser and I changed the path of the cookie from "/bonita" to "/" in the file context.xml of Bonita. Then I have added javascript code to eliminate this cookie each time the theme of Liferay was reloaded (on page refresh), thus ensuring that the old cookie was destroyed. Every time after, when the Bonita url is visited the updated cookie is recreated from the new CAS session and everything seems to work fine. A better approach would be to destroy the cookie in the CAS logout jsp page, but I didn't manage to do it like this.
Related
I have successfully installed liferay 7 and configured CAS 3.6 for SSO. Everything is working fine. I was able to create users, assign roles, create pages etc etc.
After few days, I was trying to create a new user via admin, I got warning "User 30810 is not allowed to access URL https://mysite:8443/group/control_panel/manage and portlet com_liferay_users_admin_web_portlet_UsersAdminPortlet". I could not able to create user. and from then that user does not have any permission that I use to do earlier.
I googled a lot on this, got few suggestions like
1) Adding below in portal-ext.properties:
redirect.url.security.mode=domain
redirect.url.domains.allowed=*.mysite.com
session.timeout.warning=0
session.timeout.auto.extend=true
2) Some links:
https://web.liferay.com/community/forums/-/message_boards/message/92226678
3) Somewhere it is mentioned that this it is bug with liferay started from liferay 7 GA4
4) If you read the link, it is mentioned that it related to Guest user and session expiration that starts causing this issue etc.
Had any one gone through this issue? Is there any solution or workaround for this?
I could not able to update this question with all the option I tried or solutions that is mentioned on google or liferay's official jira sites however I will keep updating this question with proper references.
Meanwhile
Do provide your suggestions/solutions.
"this starts happening when some session automatically logs out"
This phrase tells me several things, like the possibility of an user logging out even though you set "session.timeout.auto.extend".
Two basic scenarios where this can happen is:
When you close your tabs, after the assigned timeout, the user will be logged out. And when you got back, especially after a browser crash or using the back button, your browser used old data.
When you have the auto session extension working with a big timeout, leading to the possibility that the session timeout configured in Liferay being bigger than the one configured on the server.
On the last case, one might be interested on completed the config you exposed with short timeouts.
session.timeout.warning=0
session.timeout.auto.extend=true
session.timeout=5
session.timeout.redirect.on.expire=true
I know it is an old thread but it may help someone...
The "extend session" functionality is not working correctly and the final user session is expired, so when they try to log in, they have the wrong CSRF token from the previous session:
You have to double-check that the session.timeout Liferay portal.properties has the same value as the session timeout configured in your application server.
You have also check that the session.timeout.auto.extend.offset is greater than 60 seconds to avoid having problems with the chrome javascript intensive throttling
I am working on a financial web application.
There is a client requirement that if user is logged in and already browsing the app. If he copies and pastes the browser url to another window. In another window, the user should get logged out.
I know http is stateless and there is no inbuilt browser mechanism (cookies etc) to solve it, this needs to be implemented by programming only. I guess people have already solved this problem. Do you know know possible solution to solve this issue?
Sadly, there is no solution.
The browser keeps the cookies and all of the user informations for all the Tabs & Windows you open. It will clear the datas (like cookies that ask to be removed after the session) as soon as you close ALL tabs and windows of your browser. Note that if the user use another browser, the behaviour your want will be respected — browsers dnn't (yet ?) share this kind of informations.
It is simply not possible to solve the problem with code, and you'll have to find work-around.
As a researcher, I've seen one of these solutions : de-auth the user on the HTTP_REFERER (Apache Env. Variable). As soon as the referer was not the application itself (except for the login form), the user was de-authed. But take care of it : the Referer is an info sent by the browser. And no information sent by the browser should be trusted :). The advice remains, if only you want to use Javascript. You'll find someone to use a JS-disabled-browser to bypass your verification.
That's why Application Development is not yet dead ;)
Cheers.
K.
When a user hits login page of a Portal (it could be Liferay, Jboss Portal..), JSESSIONID cookieis created by the container. After entering credentials in the login page, same JSESSIONID gets carried over.
Here, end user will come to know the JSESSIONIDbefore he could get authenticated (by checking the JSESSIONID in the login page). This will increase vulnerability of the site for hacking because one can know the JSESSIONID before one gets authenticated.
This post advices to have a different JSESSIONID after authentication.
So, creating a new JSESSIOND can be achieved by Portal server being used (am using Liferay CE 6.0) or it has to be handled by web application developer? If it has to be handled by web application developer what is the best way to do? request.getSession(true) is the only option?? If I need to instruct Liferay to create a new JSESSIONID after authentication how it can be done?
This looks a lot like the session fixation problem I solved for Liferay 5.2.5 a long time ago. The solution consists of creating a custom Tomcat Valve that will force a new session ID. So the solution isn't really specific for Liferay and is dependent on if you use Tomcat or not.
I suspect it shouldn't be too difficult to adapt my old solution to a newer Liferay/Tomcat combination. You can find the necessary information about my solution in my old and currently unmaintained blog (if I only had more time...): Fixing session fixation in Liferay
The problem here is not that the user knows the session ID (the user always knows it, it is sent by his browser). The attack scenario is that the user, while logged out, clicks on the link that already has JSESSIONID embedded, then authenticates and this session becomes a logged-in session. Now someone who initially created the link can use the same session to act as the user. More details at https://en.wikipedia.org/wiki/Session_fixation
So yes, use the web or app server to re-set session ID after a user authenticates. You do not need to write it yourself. For Tomcat 7: http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
You can fix this issue by setting the following property to true like Liferay has as default.
#
# Set this to true to invalidate the session when a user logs into the
# portal. This helps prevents phishing. Set this to false if you need the
# guest user and the authenticated user to have the same session.
#
# Set this to false if the property "company.security.auth.requires.https"
# is set to true and you want to maintain the same credentials across HTTP
# and HTTPS sessions.
#
session.enable.phishing.protection=true
#Thiago:
This session.enable.phishing.protection=true is by default true in portal.properties. Anyhow, I have added this entry in portal-ext.properties. But, even then JSESSIONID remains same before and after login.
I have implemented a filter as per this link. After implementing this filter, when I hit login page of Liferay, one JSESSIONID gets created. After I enter the credentials and login, the same JSESSIONID is retained.
I have implemented this filter in a Servlet and not in any of my Portlets or in Liferay's ROOT application. My Servlet is deployed in LR + Jboss AS bundle. Am first hitting the Servlet and from here I have a link which will redirect to Liferay's login page. I have implemented this filter in my Servlet because Container will append JSESSIONID for first time request as it doesn't know if cookies are enabled or not. Since, JSESSIONID is getting appended, am not able to retrieve my images in Servlet (because url is myImage.jpg;jsessionid=). Hence, I have implemented this filter.
Is this filter conflicting with Liferay's configuration? Even after setting session.enable.phishing.protection=true same JSESSIONID is retained means what else could be the problem?
Put this code inside the portal-ext.properties.
It will fix the problem, each and every time logged in, new session id will be generated.
session.enable.phishing.protection=true
com.liferay.util.servlet.SessionParameters=true
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
From a recent audit of our Plone 4.01 instance:
Where possible encrypt the username stored in the session cookie, or use the one-time session ID to identify the user (at the server end) instead of the username.
The usernames were stored in the applications session cookie using base64 encoding, which can be easily decoded.
Invalidate the session ID immediately when the user logs out.
When logging out of the PLONE application, the application deletes the cookie, however does not invalidate the user session ID. It was also noted that authenticating with the application a second time did not invalidate previous session cookies.
We would prefer not to add another product to the stack to resolve these findings if possible.
Btw we do have Beaker installed and this is being used for public accounts as part of the ecommerce area of the site, whereas the content admins/authors are using the standard Plone login/security mechanism which is what is drawing the audit findings... perhaps Beaker can be reused for the content authors as well? Not sure if this is a good idea though...
Btw we are also updating to Plone 4.2 soonish.
If you are concerned with cookie security, you should always use SSL encryption. The same username is included in the page output, for example, so the fact that it's included in the cookie as well isn't a information leak as such.
The cookie uses a cryptographic hash that has a limited timespan, the default is 12 hours, after which the cookie will no longer be accepted.
You can lower this timeout:
go to the ZMI of your plone instance
Find the acl_users folder, then the session plugin:
Go to the Properties tab (right-most tab)
Change the "Cookie validity timeout (in seconds)" property to a new value.
Take note of the "Refresh interval (in seconds, -1 to disable refresh)" value below it though; whenever the signed cookie is older than the refresh interval, a new cookie is generated, to refresh the cookie lifetime. So, by default, once every hour, you are issued a new cookie that is valid for 12 hours.
You don't want your cookie validity timeout to fall below the refresh interval. If you set these values very low, you may want to think about using a periodic AJAX 'ping' request to keep the cookie fresh while the user is still using the site.
In fact, plone.session already includes a facility to implement this ping for you. Simply enable it by installing the "Session refresh support" add-on in the control panel ("Site setup" > "Add-ons" > check "Session refresh support 3.5", click "Activate"). This will install the javascript library for you, and it'll ping the server every 5 minutes, provided there has been some mouse or keyboard activity while the current page is loaded.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I would like to do something like play.clubpenguin.com.
What it does is that, when you visit the site, maybe using firefox or IE, if you opened a new tab or use other browser, when you visit that site again, it will show something like: "Please close the other browser that opened this page" or something like that.
How to do this? (Its client's request)
More information: The site is Flash site
EDIT:
Ok, i think this is a tough question, well, in general, Can this be done using php, mysql and JS?
Each time you serve the flash page to the user, generate a random token. Embed this token somewhere in the page, for example as a flashVar. Also, store the most recently generated token in the user's session.
Whenever the flash posts something back to the server, post the token as well. If the token does not match the token stored in the session, reject the post.
That way, only the most recently generated version of the page will have the ability to communicate with the server and if the user opens multiple versions of the page only the most recent will work.
This technique should work even if the user opens extra browsers on other machines. It doesn't use IP addresses to establish identity. And there is no chance that a user will somehow be 'locked out' permanently because every time they open the page again you reset the stored token.
It's a similar idea to the way some frameworks insert a validation token into forms to prevent Cross-site Request Forgery attacks.
try using the below code:
window.onload = function(){
if (document.cookie.indexOf("_instance=true") === -1) {
document.cookie = "_instance=true";
// Set the onunload function
window.onunload = function(){
document.cookie ="_instance=true;expires=Thu, 01-Jan-1970 00:00:01 GMT";
};
// Load the application
}
else {
// Notify the user
}
};
The code will restrict the user to open one browser tab at a time and during browser refresh(current tab) the code will not show any alert. Copy pasting the same URL in new tab will not be allowed the user to open. for more info try this
If you want to forbid access with 2 different logins, you can enforce a rule that lock on a given resource.
The client IP could be one of this lockable ressource: only one session allowed for one given IP address. That would reduce the cheating to people that have multiple public IP addresses. People that shares public IP through proxy would have problem.
I don't see what other lockable resource you can use easily.
A few options spring to mind...
When they first open the site, you'd need to store the user's current state in a cookie or similar, which you'd check for every time you open the site. If the state is Active, then it means they have another window open. The problem in ensuring that the state is cleared when they leave the original site window - you'd need to listen for the window.onunload event, and clear the state at that point - but you can't 100% guarantee this will happen.
Otherwise, you could place a script on the site which pings a server script every n seconds, notifying the server there is a window open for that client, and prevent new windows being opened until there is a lapse in pings.
To get more complex, you could maintain a persistent connection between the server and client (via sockets or similar), which would keep note of the same. Less calls from the client, a bit more complex to set up. See http://www.kirupa.com/developer/flash8/php5sockets_flash8.htm for basic info on flash + sockets.
Given you're working with Flash, you could look into Local Shared Objects (flash cookies) to store the state. Still possible to miss the unload event, but at least the cookie is persisted across all browser sessions and browser types.
Option 3 is the best IMHO.
Solution:
Response your clients request with a NO, because you are the webdesign guru that knows what's the best for the client's visitors. the website doens't have to appeal to your client but the client's visitors. and when they are limited so hard on their own computers they are everything but satisfied.