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
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 am in the process to design a login for a new app that will be associated with a domain, i.e. be the counterpart to an SPA.
Obviously I want to use
iOS 11 Password Autofill, and
Shared Web Credentials
I have read the documentation on autofill as well as watched the WWDC video about it. Also, I checked the article on Shared Web credentials, which I think is older than the new, reworked autofill. Said article recommends:
Do not use the shared web credentials as your primary storage for secure user credentials. Instead, save the user’s credentials in the keychain, and only use the shared web credentials when you can’t find the login credentials in the keychain.
This strikes me a little odd, because it
- Means I have to cover more possible inconsistencies, i.e. synchronize the keychain somehow wit the shared web credentials (what if I have credentials in the keychain as well as the shared web credentials, but they're different?)
- Potentially leaves "garbage" behind in the keychain if my user user uninstalls my app (naturally I hope they won't ever do this, but let's be realistic, some will)
Especially the last point had always bothered me in the past (before shared web credentials and autofill were a thing, or when my app doesn't have an associated domain). Unlike on macOS, the iOS Accounts & Passwords feature (in the Settings app) doesn't list ALL passwords, but only the ones used by Safari (i.e. the shared web credentials), correct? Keychain Access on macOS instead offers a means to view and manage all credentials, even those that aren't synchronized over iCloud.
I understand why the same is not offered on iOS, but it also means that for those passwords that my app saves (locally) to "its" keychain "part" can only be managed if I offer a UI for this in my app. And if the user uninstalls the app before using this, the item will stay in the keychain, at least it was that way when I tried it a couple of years ago.
My main question now is, wouldn't it be easier to disregard the article's advice and only rely on the shared web credentials for password storage? That's the part they can edit in Settings (if ever need be) and also it will reflect any password changes done on the website. I would design my app like this then:
First launch: App starts on the Login screen and offers the username/password via Autofill
User logs in: App saves a simple flag in the shared user defaults indicating the user is logged in.
App gets relaunched, e.g. after a device reboot: The app skips the login screen due to the flag and gets the password and user name from the shared web credentials (assuming the user previously granted it permission, of course)
User explicitly logs out: The app deletes the flag, basically setting everything back to first launch
User deletes the username and password from the shared web credentials (e.g. in the Settings app or with Keychain Access on macOS): The app falls back to the login screen as soon as it detects this (e.g. when attempting a remote request, or after relaunch), regardless of the flag. I think this matches the user intention best (if you delete a password you don't want some apps to hold onto it until you log them out)
This setup would avoid any issues with different items in the keychain and shared web storage and it would immediately propagate updates done in the webpage to the app as well (which is what I'd intent for my app anyways). Is there anything that would keep this app flow from working?
(Note: I asked the same question on the apple developer forums, so if you see that as well don't be confused. I will update any potential answers from there to here and vice versa.)
Edit to address #Aaron's answer:
Thank you so much for the info. Your answer helped me realize I misunderstood something about shared web credentials: I assumed that for an app with associated domain, you can access the credentials without user interaction (after perhaps an initial authorization). Like you can set the checkbox on macOS when an application requests credentials. I now realize this is wrong and on iOS you would always have to verify with the user, thanks.
For completeness sake, I still want to point out some of the other things you said:
You are right, we will eventually use token based authentication, so I will save that in the keychain (probably in addition to the password, see below). I just tried to keep the question simple enough at first.
Our app is like an email client where you update new incoming "mail". The mentioned "login flag" in something like the user defaults would thus just indicate whether the app should behave as if subscribed to an inbox or not. Like in Mail, you wouldn't expect to have to login even after relaunch.
For this reason I will probably eventually save the user's password in the (local) keychain along with a token. If the token expires, I can request a new one without user interaction, that's important in our general site and app design. Only if that request fails I would use the shared web credentials (updating my local copy of the creds in the process).
For what it's worth, the last point you mentioned is probably debatable. On macOS, for example (where you can edit the entire keychain, not just Safari passwords) de facto logs you out of an app. Mail, again, as an example. If the keychain item for an inbox is gone, Mail re-asks that the next time it is launched and tries to access the content (effectively a "kind of" login in a way).
Again, thank you a lot for answering, now I can close an open todo. :) Also thanks to #HamZa for giving out a bounty!
Considering this advice:
Do not use the shared web credentials as your primary storage for secure user credentials. Instead, save the user’s credentials in the keychain, and only use the shared web credentials when you can’t find the login credentials in the keychain.
The main issue here is that the shared web credentials process is a little clunky — it requires user interaction and takes time to resolve the credentials. So if the user has already authenticated with your app you want to avoid showing them the login page at all. You can do this by storing credentials in your app's keychain where you can access them immediately without a network connection or user permission.
This doesn't mean you need to store the user's password in the keychain. Typically you would store something like an OAuth access token in the keychain. The presence of this token means the user is authenticated - and if an API endpoint rejects your token then you can take them back to the login page.
This suggestion:
User logs in: App saves a simple flag in the shared user defaults indicating the user is logged in.
is possibly insecure depending on what you're hiding behind the login page, but typically any content belonging to the user should require a valid token to access, not just a bool in the user defaults.
I think this matches the user intention best (if you delete a password you don't want some apps to hold onto it until you log them out)
I disagree with this; I would not expect an iOS app to log out because I deleted a password from my Safari keychain.
The steps mentioned at Reset User Password seems a bit confusing to me.
For example, A user normally reset his password because he cannot remember existing one.
Now, the above link mentions that
The refresh token can be retrieved by calling user.token after logging in via Realm.Sync.User
But, as user does not know his current password, how can the app get the refresh token?
I seem to be missing something here, not sure what..
Would be nice if someone could explain the complete steps for password reset by user.
"Password reset" is a bit of a misnomer. The functionality in question is intended for a logged-in user to change their own password (for example, from a "Settings" or "Profile" screen), or for a user with administrative privileges to change an arbitrary user's password.
There is another common use case in which a user who is logged out and does not remember their password wishes to reset it. In many cases this process involves sending them an email with a link which, upon being visited, will allow them to specify a new password. The Realm Object Server doesn't support this sort of password reset out of the box; you may want to file an issue at its issue tracker to request it (since it seems quite important).
Context
I am using Parse.com as my backend for a mobile app. I use Facebook login only for now.
Assuming the user has logged in with Facebook and now has an account created on Parse already.
Question
Every time the user opens the app, should I do a check if his account is still valid by using PFUser.currentUser().become()? Or should I use the cached PFUser.currentUser()?
I have found out that if I delete the user account in the Parse backend, if I don't do a become(), the PFUser.currentUser() is still valid, even if the account does not exist anymore.
What is the best practice?
It's generally better to add a column to the user such as 'disabled', and when the app starts you can refresh the user, check that flag and display a message to the user and logout. That, from a user point of view, is similar to using become (at least as long as you check and notify the user).
So, you should do something if you're going to be removing or disabling users in the background. The main question is wether you fully delete the account or just delete the contents but leave the (empty) user in the system as a record.
I use MVC(4) with Identity (2.0) and my webapp have a page for admin to manage users.
One functionality of the admins is to inactive(freeze) a user account the way I implemented it:
Add a field in my DB called 'Active' and if the admin is deactivate the user the field value is '0'.
In order not to check for every user in every page of my website is to do it only when the user is trying to log in, so before I let him log in I check this field.
But now I have the problem:
Use-Case example: the admin is deactivate account of user "x" and after 10 min the user "x" enter the site and the site "Remember" him and not ask him to log in so my check will never happens.
if the site is "remember" the user and not asking him to log-in i'm in trouble, i need somehow to sign out the user.
I read about cookies and security stamp and my conclusion is:
I need to change the security stamp of the user in order to prevent the site to "remember" the user and allow him not to log in.
First thing: did i got it right ? change the security stamp of a user and the site wont remember him ?
Second thing: i notice that the security stamp is a guid so i can generate programmatically and insert to the security stamp field of the user, yes ? no ? why ?
If you have a better implementation to the whole thing...ill gladly hear it :)
Thank You
Update: Maybe if i change some field of the user in the database( a field that i'm not using like telephone) it will update the security stamp automatically ?
Update2: Even if i generate manually GUID and put it in the security stamp field(upon the DB) it doesn't force the user to log-out.
I've used javascript to get the logout to happen
<i class="glyphicon glyphicon-log-out"></i> Log off
Even if the User is remembered by the browser, he still needs to be authorized. You can always perform this check on authorization rather than on authentication. That way, even if the user is in the process of browsing the site and the administrator freezes the account, his browsing won't be able to continue, because on the next authorization, he will be logged out and unable to log back in.
Authentication: Who is this person and is he really who he claims to be?
Authorization: Is the logged in person authorized to perform this action or access this resource?
As suggested by James in a comment, I also agree that this can be implemented as a role or a claim. Look into claims with the Asp.Net Identity and I'm sure you'll find the solution much more elegant and flexible.