I need help with an issue during the database connection via JPA/Hibernate on hsqldb-2.2.8:
[AWT-EventQueue-0] ERROR org.hibernate.util.JDBCExceptionReporter - invalid authorization specification - not found: manasouza
I created some user (manasouza) with some password as:
CREATE USER manasouza PASSWORD 123 ADMIN
I'm using SQLWorkbench as my database visualizer, and with it I can log on normally.
Using JPA/Hibernate I already tried the username on uppercase and the password as '123' or as the value cryptographed showed on the PASSWORD_DIGEST column at SYSTEM_USERS database table, but had no success at all.
When you use CREATE USER manasouza PASSWORD 123 ADMIN, HSQLDB 2.2.8 throws an exception. Therefore you must have used a different password.
The user name is converted to all uppercase because it is not double quoted. For the password, you should use single quotes around the string. If you define the password without the single quotes, it must start with a letter and is converted to all uppercase. Therefore if you want the exact case, use CREATE USER "manasouza" PASSWORD '123' ADMIN
Related
Am working on anypoint studio 6.6.8 with runtime 3.9.4EE.
I have the following mssql generic database connection string.
jdbc:sqlserver://ABC.org:59000;databaseName=master;username=nrp;password=*37n%3b#wu;5r:;_1z~(f{1y{j
Test connection gives me the following error:
Test connection failed:
org.mule.module.db.internal.domain.connection.ConnectionCreationException: Cannot get connection for URL jdbc:sqlserver://ABC.org:59000;databaseName=master;username=nrp;password=<<credentials>>;5r:;_1z~(f{1y{j: The connection string contains a badly formed name or value
PS: I have 2 semi colons in password
I have seen similar question raised here earlier a few times, hence my question might look repetitive.
however I tried the following solutions given in the replies. none of them worked. Please let me know if you have any alternate solution.
Enclosing the password in single quotes.
adding \ in front of ;
Enclosing password within double quotes or {}
Am not the admin hence removing ; from password cannot be done.
The connection string is in a format known as JAVA JDBC URL. It is similar to a normal URL. Many characters are not allowed in URLs and have to be encoded with the URL encoding method. Try using URL encoding for the entire URL. You can do it with most languages or online pages, though you might want to avoid public pages for sensitive information like passwords.
Example in Groovy: https://stackoverflow.com/a/10187493/721855.
Example in Python: https://stackoverflow.com/a/5607708/721855.
Thank you #aled
So the {} did work. I was doing it the wrong way.
I was encrypting the password & later concatenating {} to the decrypted password right b4 passing the connection string.
What worked was that I enclosed the password in {} first & then encrypted it.
I am currently working on a project that uses OpenAM 12.0.2 with OpenDJ 2.6
We had a requirement to make the username editable. So, we ended up creating a custom ldap attribute called loginId and updating OpenAM config to use this attribute instead of uid.
When I import less than 4000 users, login works fine. When I import 4000+ users login doesn't work for any user, even 1 of the first 4000 users in the directory.
I can manually ldapsearch for the users and they exist in the directory, but I can't login with any of them.
We get an "Authorization failed!!" error, which is different to the usual username/password doesn't match error.
If anyone could shed any light on this, I would appreciate it.
Thanks
Edit
Here is the attribute definition I am now using.
attributeTypes: ( 1.3.6.1.4.1.37238.2.9 NAME 'loginId' DESC 'username (that can be updated)' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'project schema')
I have rebuilt the indices and still having the same problem :(
That is probably because your instance of OpenDJ is configured to reject unindexed search request and you haven't defined and built an index for the loginID attribute.
In Gforge, when a new user tries to log in; the user is automatically registered by fetching data from LDAP. It works fine for other users but one particular user is not able to log in and gets the error LDAP Authentication failed: Invalid Credentials . I don't understand what could be the issue? Could you please help?
This is the search function I am using.
ldap_bind($ldap, $dn, $pw)
$dn = ldap_get_dn($ldap, $entry);
$entry = ldap_first_entry($ldap,$res);
$res=ldap_search($ldap, $sys_ldap_base,$sys_ldap_id_attribute . '=' . $id,
array());
If it works for some users but not for one specific user, then it's something to do with the LDAP configuration, or with the characters in that user's ID or pwd.
Is the failing user in a different org/OU? Do they have accent characters in their username or password? These things can cause compatibility issues between GForge and the LDAP server.
Does this user have a much longer user name than other users? There is a GForge config setting called "usernameregex" that governs the complexity and length of allowed user names. Even though LDAP logins result in automatic account creation, the validation of the user's unix name might fail due to the regex in place. The error noted above could certainly be the catch-all message when this happens.
The default setting is "^[a-z0-9_.-]{3,15}$". You can change the upper length limit by changing the 15 to something else. The unix_name field in the GForge database is TEXT, so it can be extremely long (1GB?).
In GForge 6.3.x and earlier, you can find that setting in /etc/gforge/gforge.conf. Change the value and then update the system using:
cd /opt/gforge/bin && php create_config_cache.php
In GForge 6.4 and later, you can use the gf-config utility to set the value. It will take effect right away:
/opt/gforge/bin/gf-config set "usernameregex" "new regex value"
I have a database-project, created based on my existing database. It also added the scripts for creating users. One of those scripts is =>
CREATE USER [JOOS_NT\Indigo.Development] FOR LOGIN [JOOS_NT\Indigo.Dev.svc];
This script works fine on my database. But in my database-project this script is throwing an error when I build it. The error is:
"SQL70527: 'JOOS_NT\Indigo.Development' is not a valid name because it contains characters that are not valid."
It seems the "\" in the [JOOS_NT\Indigo.Development] is not allowed. However on the database itself I can run the query and it works fine. If I change it to [JOOS_NT/Indigo.Development] I don't get the error, but when comparing the scripts in the project to the existing database, it would drop the user ([JOOS_NT\Indigo.Development]) and replace it with ([JOOS_NT/Indigo.Development])
What am I missing?
Answering for someone who will look in the future.
On the database project, if a '\' character is included in the user name, the login should match the user name.
Because that, this don't work:
CREATE USER [JOOS_NT\Indigo.Development] FOR LOGIN [JOOS_NT\Indigo.Dev.svc];
But this will:
CREATE USER [JOOS_NT\Indigo.Development] FOR LOGIN [JOOS_NT\Indigo.Development];
Or
CREATE USER [JOOS_NT\Indigo.Dev.svc] FOR LOGIN [JOOS_NT\Indigo.Dev.svc];
I'm not sure if this is the expected behavior or a bug.
This is by design. The core issue is that in the "CREATE USER FOR LOGIN" based on a windows user login, if you are using a domain name for the user then this must match the login's domain name + login name. See this post on MSDN
Using Apache mod_auth_basic and mod_authn_dbd you can authenticate a user by looking up that user's password in the database. I see that working if the password is held in clear, but what if we use a random string as a salt (also stored in the database) then store the hash of the concatenation?
mod_authn_dbd requires you to specify a query to select that password not to decide if the user is authenticated of not. So you cannot use that query to concatenate the user provided password with the salt then compare with the stored hash.
AuthDBDUserRealmQuery "SELECT password FROM authn WHERE user = %s AND realm = %s"
Is there a way to make this work?
Looking at the Password Formats for Basic Auth it seemed that I could make this work if the hash is done using the apr_md5_encode function.
Found another question that relates to this and links to a Java implementation. I used that implementation with a small change to calculate the database hash inside my website normal user-creation flow. After this i could use mod_authn_dbd with this query:
AuthDBDUserRealmQuery "SELECT CONCAT('$apr1$',password_salt,'$',password_hash) FROM users WHERE user = %s AND realm = %s"