So, I think it is because of the JSESSIONID cookie that is causing the problem, but not too sure, here goes.
Basically, users are required to enter a special token when logging in. But somehow users are able to access the private/member pages even without entering that token.
So user enters credentials minus the token, errors pops up, user ignores it. Of course since there is that error, user is not directed to the members pages. BUT user can manually type in the specific member page and get access to it.
user goes to mysite.com/home
user enter username/password, no token --> error pops up
user ignore the error pop up, enters mysite.com/member/home manually and get access to it
I believe it is the jsessionid, once i remove that cookie the access to the members page are gone as well.
Any ideas?
Actually, it is not jsessionid that is causing the issue, but some weird servlet doing weird stuff...
Related
Is there a way to stop accounts.setAccountInfo from deleting an email if it is the last standing login ID?
Currently if I have 2 verified emails both loginIds and issue 2 requests removing one email at a time (I know I can pass a comma separated list) I end up with an account that can't login anymore as no login Id is left.
Both return 200 ok and no error code.
I've looked for an etag implementation so I can at least force some sort of an optimistic lock but couldn't find support for it.
Any ideas?
This is by design, as in the case a user's email(s) were compromised, there needs to be a way to disable login of the account until the user can have their information updated via a customer service representative. There is no out-of-the-box way for an end-user to use this particular parameter, so, unless a currently logged in user is manually calling the method from the JS console, there is no way for this scenario to accidentally happen.
From the server-side, if you are worried about a specific application from calling this method and require restricting a specific app from accessing this particular API you can assign the application key to a permissions group with restricted permissions. ref:https://developers.gigya.com/display/GD/Console+Administration#ConsoleAdministration-PermissionGroups
If you think this behavior should change, please open a ticket from your Gigya/CDC account dashboard for investigation.
I'm using hosted screen of Auth0. I want the following scenario to work-
Let's say I have 2 apps- app1 and app2.
One of the users signed in by providing email+password in app1.
User then navigated to app2.
Auth0 detected that the user has already signed in, so it redirects the user back to app2 WITHOUT having her signed in again.
But what I'm facing is this screen-
How can I save my user this additional click? How do I implement silent authentication? I know that you have to pass prompt=none to /authorize api, but since I'm not manually calling the api, how do I make the lock call /authorize with prompt=none?
What you want is silent SSO which is related to SSO but kind of independent.
The key is in the prompt param. This needs to be none in order for the user to not be prompted for login when he's already logged in Auth0's Authorization Server ("central SSO").
One annoying thing I found is that prompt is taken literally, so if the user is not logged in yet, he will not be prompted to login (you'd think it'd make sense to prompt the user when not logged right?).
In this case SSO will redirect to your app's /authorize with an error like "authentication required" and you'll have to handle it by redirecting the user to your /login endpoint again but passing prompt=true so that it knows that this time he'll have to pass prompt=true to Auth0's hosted login page.
To make things a bit uglier, currently passport-auth0-openidconnect seems to ignore the params you pass to the strategy unless you monkey patch one of the methods involved (I created a PR for it, don't when will be approved and/or if makes sense).
Essentially:
Pass prompt=none
If user is already logged in, he will silently be logged in your app as well
If user not logged in, user will be redirected to your app with "login required" error
In that case you'll have to pass prompt=true
I know it's a bit fiddly but I hope this helps you :)
PS: Another thing to bear in mind - I now just found out that it works perfectly when using Github as connection but when using google-oauth2 it blows up complain about the prompt param :|
I'm trying to create a new user in MODX REVOLUTION 2.3.0 but for some reason, the user cannot access the manager area. I tried to clear every bit of cache as well as to made sure the password is created by the system (email has been sent) and the user belongs to the Users Group.
Strangely, when looking at the user settings, it says that the user has made some 10 logins, but in reality, he has not.
When I type a wrong password, I get the wrong password error message, when I type a correct password, the input field gets cleared and nothing else happens.
Any idea how to solve this?
Thanks.
It seems that user don't have access to mgr context. Any user needs «frames» permission to get access to the manager.
Try to update user's data and make him a sudoer. It'll help to understand if wrong permissions cause the problem.
Exactly. Like #proxyfabio said, he needs access to the manager. To at least asses if the user login works, give him temporary SUDO rights. If that works, work your way from the ground up.
Make sure an Access Policy Template and Access Policy is created. Make sure the policy contains "frames" and is checked at the Policy Template edit screen. Next, PLEASE, make a separate Role, like "Customer". Go into the Aministrator group (or again, PLEASE, create a Customer group) and head on over to the Users tab. Add the User to the group with the Role Customer - "your level" (I usually use increments of 500 or 1000).
Under Context Access, add the user to the mgr context with the specified role and your Customer policy. Do the same for web if you with to avoid any in depth issues.
Finally, save your settings, flush your permissions, clear your cache and optionally flush your sessions table (you can also delete cookies for the browser you're using). When you've done all that, create an Incognito tab in Chrome or Firefox to avoid issues and try the login again.
I have somewhat the same issue if I try login a duplicate manager user from an android phone, the login count goes up, wrong password gives error and correct password just refresh the login page.
However logging in from a computer works. Initially it didn't...
Here are my steps:
Duplicate manager user
Set new password
Login fails
Click forget login for e-mail
Login successfully (computer) with the new generated password
Change original password to original password!? :D
Login works everywhere except my phone
I am unable to revoke application access by a user via either a password reset or by explicitly clearing app keys in user management. The latter method gives a reply indicating that access has been revoked, but when the user hits the tool, they are not re-prompted to approve access to their information.
There are number of possibilities here:
It's possible that there is latency between the declared revocation of keys and the cleanup task that goes through the database and actually cleans them up; I believe that at one point, such a latency existed, was identified, and fixed through service packs and subsequent releases. Accordingly, you may address this issue by ensuring that your back-end service is up-to-date with its available service packs.
It's possible that what's being revoked is the keys, and the necessity to authenticate to rebuild keys, but not the confirmation step that would appear to the user asking for access permission (assuming the user once authenticated, and checked the "don't prompt me to ask for permission again") dialog.
Can you confirm if the request for user tokens by the client application actually does get back tokens? Or is it just that the authentication step happens with no notice of client confirmation to access?
Note that the re-authentication might appear to happen silently; if the client application's request for user tokens happens through a user's browser context where the back-end service can determine that the user is already logged in to the LMS, then the request for tokens could succeed automatically:
The user is assumed to have already authenticated in order to have an active web session, so there's no need to re-gather a username/password (or whatever user auth step the LMS uses) to re-confirm identity.
The user may already have confirmed access for the application and dismissed the confirmation step with "don't ask me again". If the user has confirmed access with "don't ask me again" this choice will get remembered, even if the user tokens get expired due to password change or access revocation by an admin.
If you explicitly log a user out of their LMS session, and then test the client app, this should indicate to you visibly whether the re-authentication step is actually taking place (the user's browser will then get directed to the login process for the back-end service).
Note that, although a user password change or access revocation by an admin can remove the recorded user Id/Key pair associated with an application, it does not remove the record of the confirmation form having been dismissed with "don't ask again". Currently our system does not expose a way to reset that confirmation state.
If after considering these points you feel you still have an issue, I would encourage you to open a support incident through your organization's approved support contact, or your account or partner manager. Desire2Learn takes security related reports quite seriously, and if you've uncovered an issue that hasn't yet been addressed, I would encourage you to report it as a defect.
I've got a Rails 3.0.9 application using Devise 1.4.9. I'm having a bit of a problem with the login screens. I think I understand the problem as I've previously fixed a similar issue in a C application. But this time I'm just using devise so it is harder to just fix the source code ...
The basic pattern is I log out of the application, which takes me to a URL such as this: http://10.0.0.25:3000/devise/users/sign_in
I then go home and come back to work the next day, with the above address still open in the browser. I type in the password, but I just get a message saying my session has expired, and I have to re-enter the password.
Making an educated guess, when the user is shown the sign_in page, devise creates a new session which is not currently logged in. When the user submits the page, devise checks the session exists, and then checks the credentials. For security reasons, the credentials will not work for an expired (or unknown) session.
The fix in the C application was to allow a very long timeout for sessions that had never been logged in. Once a session is logged in, it does need to be logged out after an inactivity delay that is relatively short, so just changing config.timeout_in wouldn't be enough.
EDIT: I've noticed by messing around with the timeout set down to 1 minute that the not-logged-in session timeout does not change to one minute (in fact I haven't really noticed whether it has changed at all...) So there must be something else that does this.
Also I realised when a session is not logged in, there is no time stored within the session cookie, so I don't even know exactly how the server determines the session age (I don't have a server-side sessions table).