I used set_my_commands to specify command for user by specific id, but later user status changed to default scope.
Now I want show all command (and command updates) from default scope for this user without specifying user id. But I can't reset scope for user and telegram shows commands setted by user id not for default scope.
How to reset bot scopes for user(s)?
Code example:
await bot.set_my_commands(
admin_commands,
scope=bot_command_scope.BotCommandScopeChat(chat_id=user.id)
)
and now next command doesn't change anything for this user
await bot.set_my_commands(
commands,
scope=bot_command_scope.BotCommandScopeAllPrivateChats()
)
but the user is no longer an admin and enters the default scope.
Related
I am using AWS cognito API to create User in pool. User is being created successfully in Pool.
Following is the code for that . But this code create user with FORCE_CHANGE_PASSWORD state but I want to create user in UNCONFIRMED state. Can someone help me on this?
AdminCreateUserRequest cognitoRequest =
new AdminCreateUserRequest().withUserPoolId(id)
.withUsername(r.getEmail())
.withTemporaryPassword(r.getPassword().trim())
.withUserAttributes(new AttributeType().withName(Constants.EMAIL).withValue(r.getEmail().trim()))
.withUserAttributes(new AttributeType().withName(Constants.EMAI_VERIFIED).withValue("false"))
.withUserAttributes(new AttributeType().withName(Constants.GIVEN_NAME).withValue(r.getFirstName().trim()))
.withUserAttributes(new AttributeType().withName(Constants.FAMILY_NAME).withValue(r.getLastName().trim()));
You can use SignUpRequest to create user with unconfirmed status
SignUpRequest request = new SignUpRequest().withClientId(clientId)
.withUsername(userSignUpRequest.getUsername()).withPassword(userSignUpRequest.getPassword())
.withUserAttributes(emailAttr, groupAttr);
return cognitoClient.signUp(request)
After signup, user will get code on the email mentioned during signup.You can confirm user signup using different request taking code from user as input.
I setup an ApacheDS with default password-policy enabled. For testing proposes I locked a simple User (objectClass=Person extended with some custom User-objectClass) by entering the wrong credentials a number of times. As I expected the user was locked (error msg: user was permanently locked).
The question now is: How to unlock the user again? Is there a better way then just deleting and adding again?
I tried the same with an extended user (objectClass=pwdPolicy) but no pwd* attributes were added when the user was locked.
More recently, I encountered the same problem at work. But, it seems that there is no answer on Internet. Finally,I found the answer by viewing this document:
Password Policy for LDAP Directories draft-behera-ldap-password-policy
At section 5.3.3: pwdAccountLockedTime
This attribute holds the time that the user's account was locked. A
locked account means that the password may no longer be used to
authenticate. A 000001010000Z value means that the account has been
locked permanently, and that only a password administrator can unlock
the account.
At section 5.2.12: pwdLockoutDuration
This attribute holds the number of seconds that the password cannot
be used to authenticate due to too many failed bind attempts. If
this attribute is not present, or if the value is 0 the password
cannot be used to authenticate until reset by a password
administrator.
Through above two section, we can assume that we should connect to ApacheDS server with administrator(by default: uid=admin,ou=system, password=secret ), and delete the user's userPassword attribute. By this way,the permanently locked user can be unlock.
I practiced this sulotion and it works well.
I suggest you should set value for pwdLockoutDuration attribute, in this case the user can not been permanently locked.
For more infomation:
ApacheDS password Policy
Use ApacheDS Studio and log in as admin, find the user, right-click and choose "Fetch->Fetch operational attributes". Now pwdAccountLockedTime is visible and you can delete it to unlocks the user
The answer by Mister's is perfect to unlock an account and if you want to set the pwdLockoutDuration for a single user (assuming the user has implemnted the objectClass pwdPolicy.
There is also a global config file found in:
ou=config
* ads-directoryServiceId=<default>
* ou=interceptors
* ads-interceptorId=authenticationInterceptor
* ou=passwordPolicies
Here we can set the default password policy:
As mine is just a test-server, I have completely disabled lockout via setting the ads-pwdlockout to FALSE. For more on configuring password policy read the official docs.
For reference, this is how you enable this on the server via java:
AuthenticationInterceptor authenticationInterceptor = new AuthenticationInterceptor();
PasswordPolicyConfiguration config = new PasswordPolicyConfiguration();
config.setPwdLockout(true);
authenticationInterceptor.setPwdPolicies(config);
Client methods can then be written, to enable/disable specific accounts, similar to:
public void disableUser(String dn) throws LdapException, UnsupportedEncodingException
{
Modification disablePassword = new DefaultModification(
ModificationOperation.REPLACE_ATTRIBUTE, "pwdAccountLockedTime","000001010000Z" );
connection.modify(dn,disablePassword);
}
public void enableUser(String dn) throws LdapException, UnsupportedEncodingException
{
Modification disablePassword = new DefaultModification(ModificationOperation.REMOVE_ATTRIBUTE, "pwdAccountLockedTime");
connection.modify(dn,disablePassword);
}
I am trying to find a solution which will allow me to change a user's password from our Central User Administration (CUA) system where the user's access and password is on the child system.
I tried to use BAPI_USER_CHANGE with destination call but it doest suit in my case.
(we locked change password function in child systems). This is my code with destination call
CALL FUNCTION 'BAPI_USER_CHANGE'
DESTINATION 'CLNT_500'
EXPORTING
username = p_bname
password = wa_password
passwordx = wa_passwordx
TABLES
return = it_return.
Any suggestions welcome.
We tried to do something similar a while ago, and we ended up doing it in two steps:
BAPI_USER_CHANGE sets an initial password for the user
SUSR_USER_CHANGE_PASSWORD_RFC sets a productive password. It needs the old password as a parameter, that's why we needed to call BAPI_USER_CHANGE first.
What is the best way to reset password only with token?
Now it mades with token and email, I want to get an email by checking tocket in reminders table.
Thanks!
Update
Resolved this by:
$email = DB::table(Config::get('auth.reminder.table'))->where('token', $token)->pluck('email');
Here's how I do password resets.
User clicks Forgot Password link and is taken to a form with one field for email.
They enter their registered email address and I check the email exists in the DB. If it does, I store a random reset code for that user using Str::random(60). I then save the user and email them a link with a reset code (eg. http://domain.com/reset/CODE).
User clicks the link and is taken to the URL above which checks the CODE. If the CODE exists in the DB, the password for the matching user is reset to something random using Str::random(10) and this new password is mailed to the user.
Not sure if this is right/wrong, but it works for me.
By default, devise uses an email address for sign up and sign in.
But I want that the email address should be allowed to be changed by the user.
If I allow the user to edit the email address, and the user specifies an "incorrect" (i.e. a typo by mistake) email address and then user signs out, and the user also forgets what the typo'ed email was, now the user account is inaccessible by the user!
How to best work around this? (except for creating a separate, unchangeable username field that will always allow user to login)
You can force the user to confirm his account again if he changes his email.
Once, you updated the password of the concerned user, you need to un-confirm the user, and then re-send the confirmation email.
To unconfirm the user :
user = User.find(1)
if user.confirmed?
user.confirmed_at = nil
user.save(:validate => false)
end
To resend the email confirmation :
user = User.find(1)
user.send_confirmation_instructions
Hope this help !
Devise does this out of the box. Here is the info from the initializer:
# If true, requires any email changes to be confirmed (exactly the same way as
# initial account confirmation) to be applied. Requires additional unconfirmed_email
# db field (see migrations). Until confirmed new email is stored in
# unconfirmed email column, and copied to email column on successful confirmation.
config.reconfirmable = true
In confirmable module you may see how it works.