We have a Magento store and sometimes when users login it authenticates with someone elses user information.
When the user goes into my account they can see the order details of another customer.
I have found a forum that said to activate the Validate HTTP_USER_AGENT and Validate REMOTE_ADDR values under the Session Validation settings but we are still seeing the issue.
Does anyone have any ideas of what may be causing this issue?
Thanks in advance for your assistance.
George
I never really took the time to properly debug this, but some time ago we had an almost identical problem. Eventually it looked like that when System > Configuration > Web > Use SID on Frontend is enabled and you also have Magento Enterprise Full Page Cache enabled it sometimes saved the SID within cached templates. When other users clicked the link with the incorrect SID they sort of took over that session.
After disabled the SID option, we never had the problem again.
Perhaps not a real answer, but maybe valuable information for you.
Related
One of our clients wants to restrict several client accounts to be able to login only from work. (Fixed Ip)
This can not be solved through htaccess and Im not a Magento expert by no means. I have not found something usefull in google so any help would be so much appreciated.
Best Regards.
I like the idea, feel weird when you think about the use cases, but the implementation is perfectly doable.
In case we are talking about Customers, you can use customer_customer_authenticated event. Once triggered, it means that user is trying to login with correct credentials.
At this point you have to check the remote address validate it agains list of whitelisted/blacklisted IPs and throw exception (Mage::throwException('..')) with message in case you want to prevent user from logging in.
One of a parameters passed to the event observer is customer model instance, so that's cool...
If you are talking about admin users, you can do quite similar thing with admin_user_authenticate_after event.
In both cases you should have custom attribute per customer/admin where store admins can list whitelisted/blacklisted IPs.
Careful not to lock yourself out. ;)
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
We experience session bugs in our SCA website (Mont Blanc).
The session bugs are:
you are logged in but sometimes the website still shows the 'login | register' link. Ie, it doesn't recognise you as logged in.
you click the login/register link intending to login but you get taken to the checkout page
Have other SCA developers experienced this bug (SCA is known for many) and what have you done to fix this? Any advice would be very much appreciated.
Yes, It is there, We are changing our version to Elburs
Being sent to checkout upon logging in is due to the SSP application's touchpoints missing parameters. Specifically, the checkout.ssp is used for login, checkout, and register. By default, it handles checkout, but with a parameter of is=login or is=register, it will go to the appropriate places after login is complete.
I'm not sure offhand the solution for the first question.
In our website, we are displaying a change password link which redirects user to "https://account.activedirectory.windowsazure.com/ChangePassword.aspx", where user will be able to change the password.
On successful change password, we need a way to redirect user back to our application. Currently it is redirecting user to "https://account.activedirectory.windowsazure.com/profile/default.aspx".
Any help or hint is appreciated.
This is the default behaviour and currently this is not possible. There is already a similar feature request on feedback.azure.com where you can suggest new features, enhancements or bugs.
If you would love to see this feature you can upvote this feature -> http://feedback.azure.com/forums/169401-azure-active-directory/suggestions/7156218-redirect-new-users-to-application-not-manage-wind
My experience is that they are actively looking at these features and also implement them (when enough users request them).
I am writing an MVC 5 Intranet site with Windows Authentication.
The site is a questionnaire with the first two pages being information and instructions, on the third page I request the user to sign a disclaimer, from then on the user can't access any other part of the questionnaire, if the disclaimer isn't signed. What I want to do is to persist the action of signing the disclaimer to the database so when the user returns I can check if he/she has signed on a previous visit in which case I omit this page. I can't quite figure out where do I persist this information to database and where do I load it, and also how do I persist this information on the session.
Any advice would be appreciated. I have seen the suggestion on this page http://weblogs.asp.net/rashid/archive/2009/04/01/asp-net-mvc-best-practices-part-1.aspx
(see number 7) but I need to save more than just one piece of information I need to save an userinfo object.
thanks in advance.
Personally I wouldnt do it on the database, probably better doing this on the client.
You should just be able to simply set a cookie with a flag, if true omit the page(s)/Redirect else do nothing.
I guess the next question is 'do you need to know if a specific user has read the disclaimer?', in which case then store in the database as well for future reference. Depends if this flag is useful going forward or just to control the mecahanism.
Hope that helps.