I have an installation of Phabricator and a user created a username in a non standard form. The user was deleted from the approval screen.
But now its impossible to recreate the user in the new form because case insensitively the username is the same, but the email address is also the same
How can I tell Phabricator to really delete the user and start again
cd to the phabricator directory
./bin/remove destroy #username
Are you absolutely certain you want to destroy this object? [y/N] y
Sorry to answer my own question, but I couldn't easily find the answer on google, I guessed if its was in stack-overflow I'd be able to find it next time.
Related
I can successfully create an update on projects but it seems that I cannot overwrite the thread creator by ownerID.
URL sample:
https://workfronturl/attask/api/note?updates={"noteText":"test","noteObjCode":"PROJ","objID"="projectid", "ownerID":"ownerIDxxxxafda"}&method=POST
Can the ownerID be forced to another user?
If I understand correctly, you want to make an update on behalf of a user. We do this all the time as we have a system that translates updates from another system to Workfront. If this does solve your problem, please be sure to write to Workfront and tell them that they need to leave this functionality in the API in the future. I have confirmed with them that this wasn't supposed to work this way.
So, with regards to solving the problem, you need to do the following:
Login as the user who you want to make an update on behalf of. You can do this without having the users password if you have an API key. Just run the login command as you normally would, but instead of passing in a password, send the username and apiKey.
This will return a sessionID. Use the session ID to authenticate when making your update.
If your system is caching credentials, don't forget to log out or all future updates, changes, whatever, will try to use that session ID.
If you are using Python, we built a function into the workfrontapi_plus (only Python3.x) python library to support exactly this called make_update_as_user. As a note, I haven't managed to publish the documentation for this yet, but the doc strings are there and fully filled out with instructions.
I am not a drupal guy, and would hate to have to jump in and step through a login to figure out the password reset, but I CANNOT SEEM TO RESET ADMIN PASSWORD. I have searched on this. I thought this good link would be helpful:
http://knackforge.com/blog/sivaji/different-ways-reset-drupal-admin-password
so I tried the query suggested:
UPDATE users SET name='admin', pass='$S$Drl0vgZ9yuU9uc4JyaTMHxMPriC7q/PsOUOx52fCrVQSTpI/Tu4x' WHERE uid = 1
where that specific hash is supposed to represent the password 'drupal' - well, it doesn't work.
Furthermore, though I have changed the user.email field to my email, when I try and get a reset link, nothing arrives - and I've tried several emails.
I'm thinking maybe I have an older version? How may I determine this? I'm at the point where I'm ready to do a complete new drupal install, just to snip out the working portion of the login. It shouldn't have to be that difficult! I appreciate your help. Thanks
There are two main ways to do this.
You can execute drush uli, this will generate a one time login link. By default it provides one-time login link for administrator.
If you execute "drush uli some-username", this will generate one time login link for that user.
OR
excecute "drush help user-password" (Re)Set the password for the user account with the specified name.
Examples: drush user-password someuser --password="correct horse battery" Set the password for the username someuser. #see xkcd.com/936
Arguments: someuser The name of the account to modify.
Options: --password= The new password for the account. Required.
Aliases: upwd
-- To do this, you need to ssh into the root directory of you drupal installation.
Strangely, I can 'arc list' and it's okay, all my work shows up and it seems to be me.
When I 'arc land', it shows up in the commit as being applied by 'admin'
I might have generated the wrong certificate when setting it up, but re-doing it didn't work. Besides, shouldn't arc list fail?
I tried disabling the admin account, and it still applied the diff as admin. My commits appear with a dot next to them because they were applied by a disabled account.
one is set up with mymail#example.com, the other mymail+phabricator#example.com. I would try manually editing the email address to something totally different, but Phabricator doesn't seem to have the option.
Does anyone have any ideas what I could try?
Phabricator links commits based on the email address, username, and real name, roughly in order. My guess is that your local Git is configured to commit as Some User <mymail#example.com>, so when the commit is parsed by Phabricator it looks for the user with that address and finds admin. Note that the author, committer and pusher of a commit can all be different (at least, in Git).
The easiest fixes are probably:
Delete the admin account completely (you can do this from the "People" application); or
log in as the admin account and change its email address in Settings.
net website, i would like to implement forget password. I am using following steps
Form having input box for login Id and email Id and CAPTCHA
when user enter details and submit, at backend after validation new password is generated and replaced old password at database.
New passowrd is send to user at email.
Please help me whether i am doing right or not?
Is there any other secure mechanism for the same?
[EDIT]
Thanks, i got your reply. Really this is a secure mechanism. But here i have few doubt
What message should i shown to user when he enter loginId and email address at forgotten password page?
Whether message would be same for valid user and mallicious user?
Advantage of using CSRF token? Any help / link
When user click on link then what should i do; because as i guess user should automatically loggin into their account -then after that i have 2 choice (first) send new password automatically to user (second) new form will shown to user where user will enetr old password and new password twice?
Please help?
I can see why you'd want a CAPTCHA, but I'd take a different approach.
When a password reset is requested check that a reset has not already been requested for that account within the last X minutes. If a password has already been requested ignore the reset request.
Check the IP requesting the password reset. If that IP has requested a password reset in the last Y minutes ignore the request.
If the checks in 1 & 2 pass check the account exists. If it doesn't ignore the request.
If we've gotten this far generate a one time token, which expires in Z minutes and a password reset URL which encompasses this token. Email this to the registered email address. When the URL is loaded prompt for a new password and reset.
For those who believe that you should tell the user where the email has gone I strongly disagree. This is "information leakage", even if you do limit it to the domain name. For example say I've registered on JeffAtwoodEatsBabies.com as blowdart. If Jeff had requested a password reset for me and you showed the registration domain then he'd see idunno.org. This is my personal domain and thus Jeff would know the blowdart user is, in fact, me. This is a bad bad thing. I should not have to register using hotmail or gmail or whatever in order to protect myself from your code showing an email domain to all and sundry.
In addition you shouldn't be showing error messages at all. No matter what happens, a username is not actually registered, or too many requests have been made or the sky has fallen you should be telling the user that the password reset procedure has started. Informing a user that an account doesn't exist is more information leakage.
One final thing you could do is add a CSRF token to the reset request page, so it cannot be driven from other web sites.
Followup
So to answer your further questions.
What message you show is up to you. "Instructions for resetting your password have been emailed to the registered email for this account" is one idea, but really it's down to your audience.
Already addressed above.
Wikipedia is a good starting point. How you do it depends on your platform and is a complete other question! For ASP.NET you could look at my codeplex project, http://anticsrf.codeplex.com or look at ViewStateUserKey.
When the link is clicked I would first validate the token in the URL against the username it's being applied to then I would either allow the user to enter a new password, or generate a new one and email it. You can't prompt for the old one, as the whole point is the user has forgotten it!
There are many ways this has been implemented. As you said, generating a new password and sending it to the registered email address is one method. I wouldn't suggest you go that route though, as my password would be reset everytime somebody tried guessing my password.
Instead, the best thing I've seen to date is simply emailing the registered email with a link that will begin a password reset process. You may even let the user know which email address to check by showing a masked version of their email address used in registration:
An email was sent to ********#hotmail.com. Please check your inbox to continue.
Be sure to keep in consideration those of us who may forget which email address were registered with - typically a few security questions are a great way to make that information available.
I've done that recently. When the user enters their username or email address, we generate a unique token and email it to them as part of a link. Upon receipt of that email, they click the link, and are automatically logged in, taken to the my account screen, and prompted to reset their password.
Of course, this relies 100% on the security of the email client, but it's hard to beat from a usability perspective.
You shoud check the answer to the question : Can anyone provide references for implementing web application self password reset mechanisms properly? from D.W. on security.stackexchange.
It is the most complete answer I found on the subject. I also suggest you to read this article : Everything you ever wanted to know about building a secure password reset feature
I'm rewriting a website and going from a home-grown authentication model where users logged in with their account id (numbers) and password, to .NET FormsAuthentication where users will login with a username that they choose (or is available) and a stronger password. There are over 38K existing accounts and I'm trying to decide if the existing users should re-register or if I should write some code to do this on their behalf. I've already ruled out creating the usernames for the users because they won't be able to change their username. Luckily we don't have any users named Brenda Utthead.
If the user re-registers, some may gripe about having to do this step again and it may raise some support calls, but I stay with the standard process that everyone has to do. Or I can allow the user to login with their existing userid and password and then optionally give them a grace period to convert their account. I'm hesitant about the latter because it's special code and a possible threat vector because it bypasses the standard authentication mechanism and allows users to log in using less secure credentials.
This application currently accounts for about 40% of our website traffic and I'm not worried about users not coming back to the website because of the possibility of them having to re-register.
What does everyone think?
If you want your users to come back your best bet is to convert their accounts and send an email explaining the transition.
Do not make them re-register whatever you do.
You'll lose half of your users if you do that.
Give them a service so that they can enter their previous user id and have them provide their email address. Email them at the address provided and have them login with their email address as their new user name.
I am about to do the same thing. I am writing a migration page where the user logs in with his/her existing credentials and behind the scenes, I write out to the asp.net membership tables. Do a check first to make sure they haven't already migrated for all subsequent visits.
Don't make them re-register. A little work on your side is all it takes and you need to keep your customers happy.
After listening to everyone's suggestion, I've decided to modify the login. I look at the username they provide and try to guess that they're an existing user. Then I look them up in the old table and if I find a match take them to a conversion screen. There they can quickly convert their account or skip the whole process and login temporarily. The conversion form has fewer fields to fill out b/c I was able to authenticate them against the old user table so I don't need them to provide as much info.
I'm not thrilled with skipping the conversion but that option is only offered for the first 45 days from go-live.
Either convert them or find a way for both membership models to exist together, and somehow convert each user across at login or something.
Think about how long it took to get the 38k members and ask yourself if those were all wiped out, would those same people go through the hassle of signing up again. If you've got a really strong community you should be ok, the hit would just be a matter of time till you're built up.
The other thing you could do to mitigate the risk would be to send out a email, although spam blockers may filter them you could get to a high percentage of your users and tell them about the new membership stuff. Might get some older people back to the site as well in the process.
The biggest challenge is converting all the data that is associated with the user's accounts. People are going to be really upset if they've built up some sort of reputation that you're going to destroy with a new membership system.
This website is a check your balance type of website. It's not a banking site per se, but it exists as a convenience tool to users. I don't believe it would be realistic for users to cancel their accounts because they are forced to re-register.
I do like some of the ideas I'm reading in the responses though.
I would migrate their information and then on their first login ask them to confirm that their membership info is correct (just to be anal).