RavenDB BulkInsert() fails with 403 Forbidden - c#

I've recently migrated my environment and now a process that uses BulkInsert is not working. It is resulting in a 403 Forbidden response from the db server.
The previous environment had the database running as a Windows service on the same server as my application and access was set up differently. Now I'm using RavenHQ on a remote host, using an API Key. I'm sure the privileges have changed so I'm wondering if that's why BulkInsert is resulting in 403 error.
I've searched but I cannot find anything that explicitly states what privileges are required for the various raven operations. My understanding from this post is that there are at least some that require higher privileges. Can anybody point me to documentation on specifics? Or otherwise shine some light on the subject? Thanks.

I had this same problem and I think it's because the example connection string RavenHQ gives you containing your API key does not actually include your database name.
Try adding ";Database=[myDb]" to the end of your connection string URL or passing your database name explicitly as the first parameter to bulkInsert()

Related

C# MySql error: MySql.Data.MySqlClient.MySqlException [duplicate]

Trying to connect to MySQL on my web host, using Connector/Net C#/WinForms in Visual Studio 2012 Update 3, but getting the below error message:
Authentication to host '1.1.1.1' for user 'username#mydomain.com' using method 'mysql_native_password' failed with message: Access denied for user 'username#mydomain.com'#'2.2.2.2' (using password: YES)
string connectionString = "SERVER=1.1.1.1;PORT=3306;DATABASE=databaseName;UID=username#mydomain.com;PASSWORD=mypassword;";
MySqlConnection connection = new MySqlConnection(connectionString);
connection.Open();
I am connecting remotely, have whitelisted my IP (and even temporary whitelisted all (%) to test), triple checked the username and password and IP.
I originally tried the username without the domain ( username rather than username#mydomain.com) but it gave me the below error:
Authentication with old password no longer supported, use 4.1 style passwords.
Any assistance would be much appreciated, thanks!
Its problem of 'Remote Database Access Hosts'.
"You can allow external web servers to access your MySQL databases by adding their domain name to the list of hosts that are able to access databases on your web site."
MySql access is not granted to IP address of the system at which application is running.(in your case its '2.2.2.2' ).
Note:- '2.2.2.2' is your public IP address.
Two possible things:
MySQL is case sensitive make sure that the case of Database= in your connection string matches with the actual database name
You may have to grant privileges to the user.
I hope this help you.
Check your application settings file (or wherever you have stored the connection string).
In my case the application was using the old connection string (which was not valid). I was assuming that the change I made in the code of the settings file is reflected to the designer (of the settings file). But it was not!
After creating a new user in MySQL, in MySQL Workbench "Test Connection" will succeed but the C# MySqlConnection.Open() will throw the same exception and message as the question (tested with localhost and 127.0.0.1 and the local ip address).
The reason is that MySqlConnection.Open() will somehow use SELECT privilege, and you need to at least enable the SELECT privilege for the new user. The error message is misleading.
This might be related to the case of specific Membership SQL Server based instructions on ASP.NET 4.5, workaround is to create new membership in web.config, drop mvc 4 AccountControler and use old from MVC3 more here or in the internet:
http://www.nsilverbullet.net/2012/11/06/using-mysql5-as-membership-backend-for-aspnet45-mvc4-application/
In my case updated password was not used. I just generated the password using Password Generator and copy it but forgot to click Change Password.
Also check the user is added to the database and has Privileges.
For me, using the actual IP address instead of the domain name solved the problem
While Whitelisting my Ip on cpanel i had accidentally put a space in there after my ip address.[Should have been handled by them]
I added the ip again and it worked.
In my case, the problem was misleading as well.
Had quite a few windows terminals running "the same" .net app all connecting to a remote MySQL server (installed in a windows server machine). However, only one always popping the specific error when anyone clicked to run the .net application. ODBC test connection passed successfully, and no matter if the error popped, when presing OK the application continued loading successfully finally and then worked fine.But again afterwards , when anyone tried to run in for the first time the message appeared. and I repeat only in this specific terminal! The fix finally came when I noticed, that it was only in this specific terminal with the problem that we had forgotten DHCP enabled! and "although it was given always the same IP" from our IT policies, however it only worked when we disabled DHCP and set this IP, SUBNET and GW, as fixed !
Check with a program like Navicat that the mysql server user has a native password. Everything is correct but if you are getting this error check the version of the link DLL
This error; Mysql.Data.dll and Mysql Server version mismatch error. Download and install an older version
https://downloads.mysql.com/archives/c-net/
Mysql Version < 4.5
Mysql.Data.Dll version= 6.0.3

getting "ORA-01017: invalid username/password;logon denied" exception after installing Zulu

I am trying to establish an oracle database connection using connection string
Data Source=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=HOSTNAME)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=SERVICENAME)));User Id=/;
in C# native application. Here I am using operating system authentication.
When I was using jdk1.8, it was working fine but since I moved to zulu8, it is throwing exception
"ORA-01017: invalid username/password;logon denied".
This is the only change that happened over the period.
I am clueless how to solve this issue. Please help.
It looks like the connection string is not providing the full credentials. Connecting locally to oracle you can use / as a qualifying username and password via sqlplus, as the database is configured by default to do that. Otherwise, you have to specify the full username and password:
you can go here and get a good format for your connection string as if varies based on your connection method:
https://www.connectionstrings.com/oracle/

ASP.NET/C# connect to Oracle DB

I need to access a view on an oracle server with an ASP.NET website. It works if I debug the website through visual studio(press F5 in VS2012), but when I go to the version hosted on my local IIS (LocalHost/) I get this error:
Oracle.DataAccess.Client.OracleException: ORA-12154: TNS:could not resolve the connect identifier specified
A lot of the information I'm finding is related to the deprecated System.Data.OracleClient and I'm using Oracle.DataAccess.dll File version 4.112.3.0, Assembly version 2.112.3.0.
I set the AppPool it's running in to Enable 32-Bit Application=True based on some other people with a similar issue, I think everything else is default settings.
I've tried using the gacutil to make sure it is installed in the gac.
I also made a small winForms application that works and can access the data.
I've tried a couple connection strings:
This one works:
"Data Source=SOURCE;Persist Security Info=True;Password=****;User Id=****;"
This one doesn't work, I can't figure out a valid SERVICE_NAME:
"user id=****;password=****;data source=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=****)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=****)));"
I always get this error:
Oracle.DataAccess.Client.OracleException: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
Places I've looked for SERVICE_NAME
I checked the connection I was able to establish with the first connection string and the SERVICE_NAME was either blank or sys$users depending on the query I ran.
I found three files named tnsnames.ora; one was completely blank, the SERVICE_NAME in the other two were Worker and <database service name>.
NOTE: I don't have access to the server, just credentials for this one view.
I found the SERVICE_NAME with this: select sys_context('userenv','db_name') from dual; and used the second connection string from the question:
"user id=****;password=****;data source=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=****)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=****)));"
Thanks for all the help.

Azure Mobile Service login error with database and "master" user

I've been using Azure Mobile Services with my apps without much issue, but then today when I tried to pull from the service I get this error:
Exception=System.Data.SqlClient.SqlException (0x80131904): Cannot open
database "master" requested by the login. The login failed. Login
failed for user 'JVlSvKwDpdLogin_*****'.
I've never had this issue come up before, and I'm only connecting to my mobile service in code like this:
public static MobileServiceClient MobileService = new MobileServiceClient(
"https://<webservicename>.azure-mobile.net/",
"<YOUR-API-KEY-HERE>"
);
Before this error happened, I never supplied a username or password. I've seen some solutions where they've created a user for the database but I don't want to create one right now since we're still in testing and I'd rather be able to use the service without one for now. Is this an issue with mobile service, or an issue with the database?
UPDATE
As suggested by Matt's answer below, I found the MS_ConnectionString in the Azure portal. I then connected to the 'master' database on my Azure SQL server and searched for the login above. I changed the password to the one found in the connection string using
ALTER LOGIN <login> WITH password='<password-found-in-connection-string>';
But now I get this error:
Exception=System.Data.Entity.Core.ProviderIncompatibleException: An error occurred accessing the database. This usually means that the connection to the database failed. Check that the connection string is correct and that the appropriate DbContext constructor is being used to specify it or find it in the application's config file. See http://go.microsoft.com/fwlink/?LinkId=386386 for information on DbContext and connections. See the inner exception for details of the failure. ---> System.Data.Entity.Core.ProviderIncompatibleException: The provider did not return a ProviderManifestToken string. ---> System.Data.SqlClient.SqlException: Login failed for user 'JVlSvKwDpdLogin_*******'.
I haven't change anything with the connection string or the web.config file for my AzureMobileService project.
web.config:
<connectionStrings>
<add name="MS_TableConnectionString" connectionString="Data Source= (localdb)\v11.0;AttachDbFilename=|DataDirectory|\aspnet-CoverageTool.AzureMobileService-20140910083006.mdf;Initial Catalog=aspnet-CoverageTool.AzureMobileService-20140910083006;Integrated Security=True;MultipleActiveResultSets=True" providerName="System.Data.SqlClient" />
</connectionStrings>
MobileContext:
private const string connectionStringName = "Name=MS_TableConnectionString";
public MobileServiceContext()
: base(connectionStringName)
{
}
Connection String
Data Source=*****.database.windows.net;Initial Catalog=sbpconsulting_db;User ID=*******Login_sbpconsulting;Password=**************;Asynchronous Processing=True;TrustServerCertificate=False;
This error could also appear if your Entity Framework database initializers are not compatible with the permissions of the database user that your Azure Mobile Service is using.
For example, when you create database for a Azure Mobile Service, Azure automatically creates a DB user for your service. This user does not have admin permissions - it can generally read and write data to a table. In that case, if you are using DropCreateDatabaseAlways DB initializer your user will not have sufficient permission to actually drop the database and you may see the error that you have mentioned.
There are new initializers that were introduced to work with limited set of permissions:
ClearDatabaseSchemaAlways - use instead of DropCreateDatabaseAlways
ClearDatabaseSchemaIfModelChanges - use instead of DropCreateDatabaseIfModelChanges
I can only think of one thing that may be the problem. Windows Azure Databases only allow specific ip addresses that you have white listed before hand.
So if you are trying to run your app from a different internet connection or if your ip address has changed then that might be your issue.
Try accessing your database directly on your Azure Management Console and allow your ip address access to the database server.
Azure always needs authentication so check your applications app.config / web.config file for credentials.
More code-based information would have been helpful to make this answer more than a shot in the dark.
Do you control the SQL login? Do you have other databases hosted on the same SQL Azure server?
That error is happening on the backend between your service tier and the database and won't be impacted by anything in the client application(s).
The account setup in the portal doesn't have the permissions it needs. Either you have found a bug, someone has revoked the permissions for that user, or the password has changed.
Based on the error message, I'd say it is the latter issue and you need to find out what the password is and make sure it is in sync with the MS_TableConnectionString setting on the Configure tab of your mobile service. You might have to reset the password for that login on SQL and also update the connection string just to make sure they are the same.
Another thing that may be a problem is EF migrations. Have you changed your model and enabled migrations? This would all run fine on your local instance and you could add migrations and update database. When you go to deploy though you'd want to enable automatic migrations to make sure the SQL Azure DB also gets the migrations applied. I've seen people have issues with this same error message (ProviderIncompatible) when it was a migrations issue.
To enable auto migrations make sure you go into the configuration.cs file and change the line of code that sets boolean property to "false" by default to "true".
I also had this issue.
My Mobile Service was connecting to my Azure SQL Database called 'Diary'. This was working ok for a few weeks. Then, without any changes from my side , I started getting the error :
Exception=System.Data.SqlClient.SqlException (0x80131904): Cannot open database "master" requested by the login. The login failed. Login failed for user 'HwRkAPcQLyLogin_xxxService'.
I fixed the issue by:
adding the user 'HwRkAPcQLyLogin_xxxService' to my 'Diary' database
assigning db_owner permissions to the 'HwRkAPcQLyLogin_xxxService' user
I used this handy tool to manage the Azure Users:
https://aumc.codeplex.com/
I did not have to change anything in the master database.

How should I validate a user's credentials against an ADAM instance over SSL?

Apologies in advance as I haven't had much experience with directories before.
I have an ASP.net application, and I have to validate its users against an Active Directory Application Mode instance running on Server 2k3. I was previously attempting a connection with DirectoryEntry and catching the COMException if the user's credentials (userPrincipalName & password) were wrong, but I had a number of problems when trying to bind as users who weren't a member of any ADAM groups (which is a requirement).
I recently found the System.DirectoryServices.AccountManagement library, which seems a lot more promising, but although it works on my local machine, I'm having some troubles when testing this in our testbed environment. Chances are I'm simply misunderstanding how to use these objects correctly, as I wasn't able to find any great documentation on the matter. Currently I am creating a PrincipalContext with a Windows username and password, then calling the AuthenticateCredentials with the user's userPrincipalName and password. Here's a very short exert of what I'm doing:
using (var serviceContext = new PrincipalContext(
ContextType.ApplicationDirectory,
serverAddress,
rootContainer,
ContextOptions.Negotiate | ContextOptions.SecureSocketLayer,
serviceAccountUsername,
serviceAccountPassword)) {
bool credentialsValid = serviceContext.ValidateCredentials(userID, password, ContextOptions.SecureSocketLayer | ContextOptions.SimpleBind)
}
If the user's credentials are valid, I then go on to perform other operations with that principal context. As I said, this works for both users with and without roles in my own environment, but not in our testbed environment. My old DirectoryEntry way of checking the user's credentials still works with the same configuration.
After a very long morning, I was able to figure out the problem!
The exception message I was receiving when calling ValidateCredentials was extremely vague. After installing Visual Studio 2008 in the test environment (which is on the other side of the country, mind you!), I was able to debug and retrieve the HRESULT of the error. After some very deep searching in to Google, I found some very vague comments about "SSL Warnings" being picked up as other exceptions, and that enabling "SCHANNEL logging" (which I'm very unfamiliar with!) might reveal some more insight. So, after switching that on in the registry and retrying the connection, I was presented with this:
The certificate received from the remote server does not contain the expected name. It is therefore not possible to determine whether we are connecting to the correct server. The server name we were expecting is ADAMServer. The SSL connection request has failed. The attached data contains the server certificate.
I found this rather strange, as the old method of connecting via SSL worked fine. In any case, my co-worker was able to spot the problem - the name on the SSL certificate that had been issued on the server was that of the DNS name ("adam2.net") and not the host name ("adamserver"). Although I'm told that's the norm, it just wasn't resolving the correct name when using PrincipalContext.
Long story short; re-issuing a certificate with the computer name and not the DNS name fixed the problem!

Categories