I have a number of technical users on this system which was recently upgraded to SQ 5.2. The system uses LDAP authentication for normal users. When I try to change the password for a technical user, I get this:
Password cannot be changed when external authentication is used
I've also tried deleting the user, then re-creating it with the new password. That attempt gives the same error message.
I've made sure that the affected users are listed in sonar.properties, for sonar.security.localUsers.
This is planned to be fixed in version 5.3 : https://jira.sonarsource.com/browse/SONAR-7036
Related
I setup a user role that has (currently) simply all resources.
I setup a user that has this role.
I authenticate with the user credentials (user and password, no store code) in zapier to create a connected magento2 account.
After some time my zap does not work anymore because the connected account cannot access my magento anymore.
I can just hit reconnect in zapier enter the same credentials as above and it works again.
But after some time it again does not work.
Looking at the magento documentation this is because custom and admin accounts expire after 1 or 4 hours.
Reading the documentation I would need an integration to have unlimited access.
But in zapier I cannot enter tokens or anything.
So I really wonder how I would set this up. If it is possible.
Or is just zapiers integration borked?
What is strange though is that this behavior began after upgrading to Magento version 2.1.11.
Other 2.1.x versions before did not have this problem.
David here, from the Zapier Platform team.
That's a known bug on our end. In the meantime, you can override this via Configuration > Services > OAuth > Access Token Expiration
I have a problem with my Camping app for which I've setup an authentication system based on this (http://nycda.com/blog/basic-user-authentication-model-in-rails-4/) tutorial.
I wanted to learn how to setup such a system from scratch to better understand the underlying logic. With this system in place users can create their accounts and login and logout without problems and authentications pass.
It took me a while to determine that the problem with authentication occurs after the user role has been updated in the database. Every user has a default role upon registration, which managers can change after registration. And after that the user authentication fails.
Prior to that there are no errors and users can navigate the application. If I inspect the database I see the user role being updated.
Is the problem related to the database update?
I'm using camping with bcrypt and activerecord 4.0.4. Please see this gist: camping auth
Thank you for your help.
Regards,
seba
Having only briefly looked through the code, I'd guess that updating the role is causing the password hash to be recreated because the logic in the encrypt_password message doesn't appear to prevent that from happening.
You could verify this by seeing if the hash in the DB changes between creation and role update. To prevent this, you could try wrapping that code in an "unless password.nil?" condition in that method.
Hope this helps.
No more works password for admin. In archiva.xml admin is in default users.
And not propose on start page to set admin password.
Already tried deleted users dir. Problems persists.
Any ideas please?
From my personal experience, I've had success by resetting the Admin password 6 times (the default amount of previous passwords stored by Archiva) to retain the same password. Make sure that the admin's email address is set to an email address belonging to an account that you can access.
You could reset your password 1 time of course, but that might entail you having to change your password in multiple places, such as your Maven settings.xml, Jenkins, etc.
We are using Sonhrqube 4.5 that is integrated into Google's oAuth sign-on. There are no issues with logging in (Authentication). Certain users have been provisioned with sonar-administrators role. But for some reason, the admin role keeps dropping for some users (leaves the user with sonar-users role). We have tried granting them admin access again, but it keeps happening. Also tried creating a brand new group and assigning that group to the user, but still same thing happens. Any thoughts? If you need any other information, let me know.
Just additional info, not sure if it matters - We are using the sonar-oauth-plugin from JCERTIFLab for integration with Google's signon/oauth. This plugin automatically creates users with default role - sonar-users.
Thanks in advance!
It turned out to be an issue with the Sonar plugin used for integration with google's Oauth. Every time a user is authenticated, permissions get overwritten. To overcome the problem temporarily, we predefined a list of users with admin access in the properties file.
I have a rails 3.2 app and I'm using devise for authentication.
I recently went to test to the password reset functionality and noticed that while the reset password appears to work (the app lets you reset the password and then logs you in) if I log out of the app and then try to log in again I cannot log in. The app reports that I have an invalid email/password combo.
I've checked that the DB is getting updated with and the reset_password_[token/sent_at] fields are getting updated correctly. The object (User object) is getting updated as well according to the timestamp. BUT, I can no longer log in with the password I just used.
I'm not sure what might be causing this. I've seen some one other related one other related post about this same issue but it doesn't really have an answer - only a clue: the salt/pepper logic.
What would allow the user to change their password but not log in again? Any ideas?
Current ENV:
Rails 3.2
Devise 2.2.4
Ruby 1.9.3
I figured out the problem. Another developer on my team had added a before_validation callback on the User object that was generating a random password for new users (because of a new simpler sign up process) and they forgot to write a test for password updating. Therefore, when the password was updated, the before_validation callback was being called and a new random password was being generated. Fixed that and wrote some tests and now its working as it should.