I have this code for an email settings form that the user will input the email address, password, etc.
$form['mail_settings']['user_pass'] = array(
'#type' => 'password_confirm',
'#description' => t('your password')
);
$form['mail_settings']['user_signature'] = array(
'#type' => 'textfield'
'#description' => t('custm signature')
);
What I wanted to achieve is to have the user be able to change his signature anytime without having to re-enter his password all over again.
What's happening right now is that every time I load this settings page there's a default value for the password and blank for the password confirmation.
So, if the user forgets to input his password again, the form displays an error. Or rather the it will create a validation error.
What should be done here?
Came up with a different solution. It turned out that my browser's password chain (saved passwords) is responsible for adding the default value in the password field.
The solution was just, if password field is empty: update password using the old one; else if not empty update password with the new one.
Related
How to inclues password after login with social network with laravel socialite? (sorry for bad english)
Com criar/incluir senha fazendo login a partir de uma rede social com o laravel socialite?
code on my LoginController
public function handleProviderCallback($provider)
{
$user = Socialite::driver($provider)->stateless()->user();
$authUser = $this->findOrCreateUser($user, $provider);
Auth::login($authUser, true);
return redirect($this->redirectTo);
//return $user->token;
//dd($userSocial);
}
public function findOrCreateUser($user, $provider)
{
$authUser = User::where('provider_id', $user->id)->first();
if ($authUser){
return $authUser;
}
return User::create([
'name' => $user->name,
'email' => $user->email,
'provider' => strToUpper($provider),
'provider_id' => $user->id
]);
}
In the socialite flow, a user will never need a password
You can set password to nullable() in the users migration file.
In 'Account Settings' a user can set a password, leaving the current password empty
Once the password is set, a socialite user can login via both social media or direct
I did two different implementations :
Generate a random password, save it with user object and send you
user an email with the auto generated password.
Create a middleware to check if password is NULL or not set and
redirect user to a form to enter password.
The objective of using the socialite authentification is that the user won't need a password.
BUT if somehow the user want to have a password, like i had earlier in one of my projects, he can easily click on forget password and he will receive a link via email to reset new password
I am working on a custom OIG password management requirement for a client.
I am facing issue while validating the password history in policy definition (eg: shouldn't match last 5 passwords used).
For some reason, PasswordMgmtService API's validatePasswordAgainstPolicy method is bypassing the history validation and returning true if user enters any old password.
Below is the code snippet for reference.
public ValidationResult validatePasswordRACFPolicy(String loggedinUserKey, char[] userPassword)
{
PasswordMgmtService pwdMgmtSvc = oimClient.getService(PasswordMgmtService.class);
User usr = new User(loggedinUserKey); //loggedinUserKey is user key of logged in user
ValidationResult valResult = pwdMgmtSvc.validatePasswordAgainstPolicy(userPassword, usr, <App Instance Name>, Locale.getDefault());
IDMLOGGER.log(ODLLevel.FINEST, "Is Password Valid = " + valResult.isPasswordValid()); //this value is true even if user tries to reset password using any older passwords.
return valResult;
}
Eventually, ending up with exception when I try to update the account password on target.
provSvc.changeAccountPassword(Long.valueOf(accountId), userPassword);
//provSvc is ProvisioningService API object, accountId is oiu_key, userPassword is the password entered by user.
Here are the exception details:
GenericProvisioningException An error occurred in oracle.iam.provisioning.handlers.ChangeAccountPasswordActionHandler/execute while changing the password for account with id 1234 and the casue of error is {2}.[[ at oracle.iam.provisioning.util.ProvisioningUtil.createEventFailedException(ProvisioningUtil.java:175) at oracle.iam.provisioning.handlers.ChangeAccountPasswordActionHandler.execute(ChangeAccountPasswordActionHandler.java:84 ... ... Class/Method: tcOrderItemInfo/validatePassword Error : Password Does Not Satisfy Policy
Using typical Rails 4.1 app with has_secure_password and the User model has a password_digest column in the DB. When I create a new user, I can still access the plaintext password in the console:
# in rails console
> u = User.new(email: "test#test.com", password: "password")
> u.save
> u.password => "password"
> u.password_digest => "xjdk..."
However, when I close the console session and start a new one, I can no longer retrieve the plaintext password:
# close above console session and open a new one
> u = User.find_by(email: "test#test.com")
> u.password => nil
I'm assuming that the plaintext password is only retrievable in the first situation because it's being stored in memory and when I call u.password => "password" it is retrieving the value from memory, NOT the database.
I had always thought has_secure_password stored the (salt + password) as a hash and I thought that meant it was theoretically impossible (if I can use that terminology) to reverse the password_digest and get the original password.
I'm just making sure my assumption that the password is stored as a real hash (ie, can't retrieve original password) is valid. I've read the Rails has_secure_password API but it didn't clarify my question.
You are correct — the DB is only saving the hashed password, not the password itself. You can confirm this by accessing the database directly using the read_attribute method (http://www.rubydoc.info/docs/rails/3.0.0/ActiveRecord/AttributeMethods/Read):
> u = User.new …
> u.read_attribute(:password_digest)
=> # Some hash
> u.read_attribute(:password)
=> nil
Incidentally, also make sure your User model does not have a password column. Otherwise it would save the password directly, defeating the purpose of hashing the password.
Is there a module that can make different registration forms for different roles during sign up? (ex. each Editor,Main User,Sub User role have different form)
Here's what you should do
start with install profile2-7.x-1.2.tar.gz.
entity-7.x-1.0-rc3.tar.gz once you have profile2 installed -->
enable --> click on configure - (Here you see your profile types
-add as many as you want).
when you add a new one or modify the existing one "Main" make sure you check "Provide a separate page for editing profiles."
4. Now to have different registration, login and password change pages
install and enable profile2_regpath-7.x-1.9.tar.gz
Now visit the profile Types Page again here you should see "UNIQUE REGISTRATION PATH" .. rest is easy ..
There is :)
http://drupal.org/project/autoassignrole
to assign by path you will also need Content Profile:
http://drupal.org/project/content_profile
check out this tutorial on how to pull it off:
http://www.web-a-team.com/blog-post/user-registration-more-one-role
Here is some idea how to solve your question in drupal 7(I think it should work in drupal 6 also). However its not safe since anyone can just change the role they have:
function my_module_form_user_register_form_alter(&$form, &$form_state, $form_id) {
$company_role = $form_state['build_info']['args'][0];
$form['account']['company_role'] = array(
'#type' => 'select',
'#title' => t('Company role'),
'#options' => drupal_map_assoc(array('editor','main user','Sub User')),
'#description' => t('Please select your company role'),
"#empty_option" =>t('- Select -'),
'#weight' => -11, // Add the select box above username that have weight -10
);
switch (strtolower($company_role)) {
case 'editor':
// add extra fields for editor
$form['account']['company_role']['#default_value'] = $company_role;
break;
case 'main user':
// add extra fields for main
$form['account']['company_role']['#default_value'] = $company_role;
case 'sub user';
// add extra fields for 'Sub User'
$form['account']['company_role']['#default_value'] = $company_role;
break;
default:
$form['account']['company_role']['#empty_option'] = t('- Select -');
$company_role = null;// error handling or default case
}
}
If you for example have LDAP in your company you could instead get this information from LDAP(https://www.drupal.org/node/1053748). Then you can be more sure about the role is chosen correctly.
I am trying to implement some tests to validate the behavior for Authlogic password resets as explained in http://www.binarylogic.com/2008/11/16/tutorial-reset-passwords-with-authlogic/
I am using Authlogic, Shoulda, Webrat and Factory Girl and here's my test:
require 'test_helper'
class PasswordResetTest < ActionController::IntegrationTest
setup :activate_authlogic
context "A registered user" do
setup do
#reggie = Factory(:reggie)
end
should "not allow logged in users to change password" do
visit signin_path
fill_in 'Email', :with => #reggie.email
fill_in 'Password', :with => #reggie.password
click_button 'Sign In'
assert_equal controller.session['user_credentials'], #reggie.persistence_token
visit change_password_path
assert_equal account_path, path
assert_match /must be logged out/, flash[:notice]
visit signout_path
assert_equal controller.session['user_credentials'], nil
visit change_password_path
assert_equal change_password_path, path
end
should "allow logged out users to change password" do
visit signout_path
assert_equal controller.session['user_credentials'], nil
visit change_password_path
assert_template :new
fill_in 'email', :with => #reggie.email
click_button 'Reset my password'
assert_match /Please check your email/, flash[:notice]
assert !ActionMailer::Base.deliveries.empty?
sent = ActionMailer::Base.deliveries.first
assert_equal [#reggie.email], sent.to
assert_match /Password Reset Instructions/, sent.subject
assert_not_nil #reggie.perishable_token
#TODO
p "Perishable Token #{#reggie.perishable_token}"
assert_match assigns[:edit_password_reset_url], sent.body
end
end
end
In the last 2 lines of the test, I am trying to make sure the link sent out has the right perishable_token and it always comes up different between the printed Perishable Token and the token in the link sent out.
How should I test this behavior?
Thanks, Siva
Careful. Authlogic is magic. Certain operations cause the User object to mutate and when it does, the perishable_token well, perishes (gets regenerated).
I wonder if your visit signout_path is really logging you out. Typically, if your UserSession is RESTful you'd have to issue an HTTP DELETE to the resource to actually delete the session. Just visiting the path (with a GET) won't delete the session unless you have an explicit route for it (mapping e.g. '/logout' to :controller => 'user_sessions', :action => 'destroy')
Change the line in notifier.rb to this:
body :edit_password_resets_url => edit_password_resets_url(user.perishable_token)