I look at the SEA API as well as the Gun User Management module, but could not find any provision for recovering or resetting user password. there would be instances where the recall flag would not be set to true. how does one go about this in the event that a user forgot their password (on the web )
Yes it is possible.
Here is a video of it working in action:
https://d.tube/#!/v/marknadal/gfqglxvd
Here is some code that helps:
https://gist.github.com/amark/755193244d28f4f4c980130055a26e5c
Related
Disclaimer: This is more of an Auth0 Lock question--there isn't an "Auth0-Lock" tag yet, if someone with 1500+ rep wants to create one.
Anyone know how or if there is a way to make it so Lock does not show the email/username and password fields on the login tab, as well as the email, username, and password fields on the Sign Up tab?
I figured it out. The search results from Auth0's site took me to old documentation.
Solution:
the OPTIONS object you can pass into the lockProvider accepts a property called "allowedConnections", which is an array of string values. I just had to list the connection options I wanted to be ALLOWED rather than letting it show all the connections I have available for the app.
Documentation for Lock v10:
https://auth0.com/docs/libraries/lock/v10/customization#allowedconnections-array-
The follow allows users to log in but not to sign up with a username/password:
manage.auth0.com
Connections
Database
Username-Password-Authentication
Settings
Disable Sign Ups
I'm looking to write an app that disallows some of the password login options (picture pw or pin) at certain moments - for myself and security reasons.
Any ideas how one would go about finding the APIs to use that can be run when the computer is locked and disallow a specific login option ?
I checked all classes under Windows.Security.Authentication, Windows.System.UserProfile, and Windows.System.Profile, but didn't see anything to toggle those login options. There are method to set the bg pic under Windows.System.UserProfile.LockScreen, but that isn't what i'm looking for - just the ability to toggle the picture pw and pin options.
If you want to alter the login process I believe you have to implement your own custom credential provider. There is a sample in the Windows SDK on how to do this.
You can find more info on MSDN.
We're setting up a feature to enable users to reset their password when they can't get access ot their account. We ask for their email address (which they use for logging into the site), send them an email with a unique link.
The questions are:
Should the link expire on first-click or should the link expire on first-use (ie, they reset their password successfully)?
Should the link have 24 hour validity (or something similar)?
Should the user be logged in after he clicks that link?
The link should expire after the password is changed. If you expired the link on the first click this can cause problems. Let's say I've got bad internet connection, and the page didn't load completely to my browser. I reload the page and it says link is expired. I wouldn't be happy user to see that.
Yes, you should limit the link to some reasonable time. 24 hours looks reasonable enough. If you don't limit the link lifetime, first of all you will have to store the generated id forever, secondly the longer you keep this link active the higher probability that link will be stolen by attacker, which will lead to stealing account.
You should let user in only after user changes his/her password. If you just log them in, they probably will decide that they don't have to change password anymore. This way they can keep logging into the system forever without ever changing/knowing their password.
The link should expire after they have reset their password successfully. If somehow the user ended up needing guidance on a password reset and wanted to return later, they should be able to.
That being said the reset should expire eventually, 48 hours?
Yes they should be logged in after a password reset, otherwise there is another frustrating step in the way of your user doing what they came to do on your site.
So I have my little Sharepoint single server farm all setup and everything was running pretty smoothly until I noticed this happening last week:
Every time someone logs in, they get logged in as "System Account" instead of "Domain\User"
I've done some extensive searching on here and Google, but the only solution that I came up with was that it was an App Pool Identity problem
Any suggestions?
**
EDIT:
**
I just wanted to say for the sake of anyone Googling this that here is how I fixed it:
In the Administration Page, navigate your way to Farm Credentials.
From there look at your Farm Account in the drop down menu, and make sure that user is set to a profile with enough privileges. Mine was set to NT\AUTHORITY or SYSTEM\NETWORK (I can't remember which; I've since stopped working with Sharepoint) and I changed it to DOMAIN\USER.
After restarting Sharepoint and IIS everything worked and all the users were logging it with DOMAIN\USER instead of "System Account"
Sounds like you are on the right track. I would first check application pool security account. Is it possible that you selected a domain group that contains all of your users?
Also, after actions that Rich Bennema provide, maybe need to perform issreset to applay changes.
I've been working on a project to create an FDA part11-compliant e-signed document repository. The mandate is that it use Perforce to track the various revisions of the documents, utilize LDAP (AD) as the authentication/access directory, and re-authenticate the user at the point they submit a changelist.
The first two requirements are in place, but I am having trouble with the last one. I have a script at the "change-submit" trigger which logs out the user - assuming that this would force the client to re-authenticate the user before continuing with the process - but this does not work, at least for the command line client; the user is logged out but the process completes, and the next command attempt from the user is the one that gets denied.
Setting the script to handle the authentication process is not an option as it is run server-side and there is no way to pass a prompt through to the user.
I could of course pass authentication as command-line arguments to the script and then return non-0 to force the process to abort if the credentials are false, but I have not found a way to modify the commands sent for a given action by the p4v GUI, nor again to have the client prompt the user for authentication; and, this would result in the password being displayed as clear text consistently.
Setting the ticket timeout to an extremely short duration would definitely require the user to authenticate prior to submission, but also before any other action.
Has anyone out there dealt with something like this before, or does anyone see an angle of attack that I am missing? Thanks!
Thanks avp for your attempt to help, but my issue was not that the logout wasn't performed, but that the submit that triggered the logout script was concluded anyway.
I basically ended up setting up different groups, one which had all rights except write, and then a group for each authorized user which had write rights, but expired in 90 seconds. I then put all users in the non-write group, and then had a trigger set on login which parsed the password given to determine if it contained a request to join the group with write rights (which was set into a p4v script) and, if the remainder of the passed-in password was correct, assigned them to that group.
I've had it in production for a few months now with no issues.
Well, I have no idea why it did not work for your client, but you can try this:
remove the p4tickets.txt file or remove the necessary line in this file after you logged out.
(After I log out I can see that one line (the line for the client I logged out) is removed from the p4tickets.txt.
Each time I have any problems with logging in/out I remove this file and it helps.