I'm having a difficult time finding information on how to get RavenDB to work on a network. Within the same network, I can have an instance of my app running, and it will show data from my RavenDB. However, when I try to write data, I get a 401 Unauthorized exception.
What is the correct way to set up a RavenDB to be accessed over the network?
Right now, I have this in Raven.Server.exe.config, which is just a short-term solution:
<add key="Raven/AnonymousAccess" value="All" />
What I don't understand, is that the RavenDB web site says to use something like this:
<connectionStrings>
<add name="RavenDb"
connectionString="Url=http://serverName:8080;user=user;password=password"/>
</connectionStrings>
Ok, that's great for the application that's running, but how do I set the RavenDB server to allow that user and password? Is that just the wrong way to do it (somehow setting the RavenDB config file to allow those credentials)? If that's wrong, how am I supposed to define credentials on the server side?
Edit: Here are my attempts and results:
I'm running RavenDB by double-clicking Raven.Server.exe.
Scenario 1
Client app.Config:
<connectionStrings>
<add name="RavenDb" connectionString="Url = http://server:8080;domain=Xx;user=Xx\user;password=pw"/>
</connectionStrings>
DocumentStore Setup:
DocumentStore documentStore = new DocumentStore();
documentStore.ConnectionStringName = "RavenDb";
documentStore.Initialize();
Save Operation:
Session.Store(objectToSave);
Result:
"The remote server returned an error: (401) Unauthorized."
Scenario 2
Client app.config:
<add key="databaseUrl" value="http://server:8080"/>
DocumentStore Setup:
string databaseUrl = ConfigurationManager.AppSettings["databaseUrl"];
DocumentStore documentStore = new DocumentStore();
documentStore.Url = databaseUrl;
documentStore.Initialize();
Save Operation:
Session.Store(objectToSave);
Result:
"The remote server returned an error: (401) Unauthorized."
Inner exception: "The target principal name is incorrect"
Create a local user on the machine RavenDB runs on and use any credentials you'd like. Then assign read/write permissions for the /Data directory (and the /Tenants directory if needed) to this user.
If you're running RavenDB as a service or standalone application, remote auth should work with the (windows)users credentials. If you're running on IIS, please make sure you have Windows Authentication enabled (disabled by default!).
For me, I had to add domain to the connection string on the prod machine, but NOT when accessing that same machine remotely... I dunno.
Of note: I created a windows user named RAVENDB, and assigned it full permissions to the data directory.
so my connection string that worked fine remotely was
<add name="raven" connectionString="Url=http://myserver.com:8080;user=RAVENDB;password=PASS" />
whereas on the actual server, i had to use
<add name="raven" connectionString="Url=http://myserver:8080;DOMAIN=MYSERVERNAME;user=RAVENDB;password=PASS" />
Bob,
By default, RavenDB uses Windows authentication. So if you create the user on the server machine, it would accept it.
The alternative is to define ravendb specific users, but many people just use Windows Auth.
Related
As a follow-up to this post: Enabling co-located Session Caching in an Azure Cloud Service - I'm trying to store session state in Azure Cache to persist sessions between VIP swaps. Quoted from the answer:
To fix this problem, I'd like you to try the new Cache Service
(Preview). In this way you create dedicate cache for your subscription
so that you can use them across cloud service deployments, virtual
machines and websites.
I've set up an Azure Cache (Preview) instance, used its endpoint and primary access key in my web.config, and deployed to my Azure Cloud Service Staging slot.
I then logged in using Forms auth, and redeployed to the same slot. My credentials were persisted! This was great to see.
But then I VIP swapped to Production, logged in the same way to the production instance, redeployed to Staging, VIP swapped again, and then refreshed, expecting to remain logged in, but it didn't work - my session was lost on both production and staging.
I've followed the instructions found here:
http://www.windowsazure.com/en-us/manage/services/cache/net/how-to-in-role-cache/#getting-started-cache-role-instance
What could be causing this? No exceptions are thrown - my access key works (tested by giving it a bogus one and getting an exception)... I'm not sure what's going on. Config sections in web.config:
<sessionState mode="Custom" customProvider="AFCacheSessionStateProvider" xdt:Transform="Insert">
<providers>
<add name="AFCacheSessionStateProvider" type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache" cacheName="default" dataCacheClientName="default" applicationName="AFCacheSessionState"/>
</providers>
</sessionState>
And:
<dataCacheClient name="default">
<autoDiscover isEnabled="true" identifier="mysite.cache.windows.net" />
<securityProperties mode="Message" sslEnabled="false">
<messageSecurity authorizationInfo="{my key}" />
</securityProperties>
</dataCacheClient>
As for timeout policy - I have it set to never expire with eviction enabled. I'm one of a handful of users and the cache is storing cookies in 128MB of space, so I don't think it's related to expiry.
I also noticed that in the docs, there is no entry for applicationName as I have above. I tried removing it and re-testing, to no avail - my Prod session is still lost upon VIP swap.
What am I doing wrong?
Update:
From a microsoft forum post:
I was able to reproduce the issue. I am investigating.
Forms authentication is not based on session state. It relies only on client-side cookies. Cookies are encrypted and validated with keys specified in machineKey section of web.config.
Default config is:
<machineKey validationKey="AutoGenerate,IsolateApps"
decryptionKey="AutoGenerate,IsolateApps"
validation="SHA1" decryption="Auto" />
AutoGenerate means that each physical machine gets its own decryptionKey. Cookies generated by production VM will not be accepted by staging VM.
After VIP swap all cookies set by old production VM will be rejected by new production VM (ex-Staging VM), causing all users to be logged out.
You need to specify machineKey values explicitly to force Forms Auth to generate cookies that will be valid for both new and old production VMs (see How To: Configure MachineKey, Web Farm Deployment Considerations section).
Check this online tool for machineKey section generation: http://aspnetresources.com/tools/machineKey.
UPD: There is a related note in Manage Deployments in Windows Azure/Managing ASP.NET machine keys for IIS:
Windows Azure automatically manages the ASP.NET machineKey for
services deployed using IIS. If you routinely use the VIP Swap
deployment strategy, you should manually configure the ASP.NET machine
keys.
i have a web application (mvc4 and .net4.5) on a web farm server and one thing is confusing me, my session id changing whiteout reason and strongly and i lose all user data that i stored them in session state. but it works fine on local machine.
i use this config in my web config:
<sessionState mode="StateServer" customProvider="DefaultSessionProvider"
cookieName="abcd" timeout="120" >
<providers>
<add name="DefaultSessionProvider" type="System.Web.Providers.DefaultSessionStateProvider, System.Web.Providers,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="DefaultConnection" />
</providers>
</sessionState>
and my machine key is this:
<machineKey compatibilityMode="Framework45"
validationKey="702C65CF39B1ED514AC4B92326C3A84B3D88990DDF784AA0895659B528ED95F8CA0A9CD1AF5ED92A2599362684CB8D204AC30D07E6BF0CF65194A5129"
decryptionKey="1C49E6BA2F9423387FBC91389A0C5C8D06B61875BCE4916A40474ED"
validation="SHA1" decryption="AES" />
my session time out is on 120 minutes and i can not find why this happening to my web application.i use my log class to view what happening on my web application and I'm sure
session id changing.
for example when user go to another area or when user want to pay money by online bank payment i redirect it to bank page and when user redirect to my site from bank in same window (i do not open another tab or window to do this) session id changed.
i store small data like user id in my session.
i use this syntax to store session:
HttpContext.Current.Session[System.Web.HttpContext.Current.Session.SessionID] = "abc"
and read by this syntax:
var myval=HttpContext.Current.Session[System.Web.HttpContext.Current.Session.SessionID]
it like that server do no use my config and do itself work.
i want to know is it possible that some configuration may be set on my farm server and it case it do not use my config and do works for itself?
To extend from comment, it looks like you have to configure your web apps correctly as per the following Microsoft Support article
http://support.microsoft.com/kb/325056
With server-side state management, if a client switches servers in the middle of the session, the new server does not necessarily have access to the client’s state information (because it is stored on a different server). You can use multiple servers with server-side state management, but you need either intelligent load balancing (to always forward requests from
a client to the same server) or centralized state management (where state is stored in a
central database to which all web servers have access).
Make sure you have the same MachineKey in all your web servers or else they can't share session data.
The objects you store in the session need to be serializable
This is a fresh install of Raven #2230, running on IIS8/Win8. When studio starts it offers to create new database, then browser pops up credentials window (401).
Web.config has add key="Raven/AnonymousAccess" value="All"/ set. Also tried add key="Raven/AnonymousUserAccessMode" value="All"/ as per documentation.
Anonymous Authentication on site is enabled, so is Windows Authentication.
Added Raven.Bundles.Authorization.dll to plugins folder (not sure if needed, but didn't make any difference).
Am I missing something ?
RavenDB as of today, is on version 2750 (stable). Upgrade and this issue should be fixed.
The way to do this is to set the AnonymousAccess setting in web.config to Admin:
<add key="Raven/AnonymousAccess" value="Admin"/>
You should change this back to All once you have created your database.
I have a web service hosted in IIS running under a domain account which also has permissions to a SQL Server. All the users mentioned below have access to this SQL Server.
Here is a fragment of the service config:
<basicHttpBinding>
<binding name="SecureWebBinding">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
... etc.
During a particular service method, I make one call to the database as the service account and wish to make another as the user who called the service (we are returning a FILESTREAM transaction context created by the calling user - these are user-specific). The first call completes but the second is wrapped as follows:
using (ServiceSecurityContext.Current.Impersonate())
{
using (var connection = new SqlConnection(...Integrated Security = true...)
{
connection.Open(); //<---Exception
After the call to Impersonate, WindowsIdentity.GetCurrent() correctly returns the calling user rather than the service account with ImpersonationLevel == Identification.
If I remove the first 2 lines, the operation completes as the identity of the service account. Of course the later call to FILESTREAM subsequently fails.
You need to setup an SPN for the server to DB as its using kerberos when you are impersonating. But it depends on the error message you are getting. This resource should help you, although im still running into issues for a similar process, but your process seems like it should work with this:
http://blogs.msdn.com/b/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx
I have an Outlook Add-In that's installed from a web server. This add-in works the same way as all other add-ins I've worked on in Office.
setup.exe is downloaded and executed
all prerequisites (.Net framework and such) are verified
vsto file is downloaded
So far, everybody installing this add-in has had no problems (this add-in has been in use for about a year). We have a new customer installing it on Windows 7 and we're seeing our first issue. Here's the error:
There was an error during installation:
Downloading http://<path and filename>.vsto did not succeed
***************** Exception Text******************
System.Deployment.Application.DeploymentDownloadException: Downloading http://<path and filename>.vsto did not succeed
System.Net.WebException: The remote server returned an error: (407) Proxy Authentication Required. ---> System.ComponentModel.Win32Exception: The token supplied to the function is invalid
at System.Net.NTAuthentication.GetOutgoingBlob(Byte[] incomingBlob, Boolean throwOnError, SecurityStatus& statusCode)
at System.Net.NTAuthentication.GetOutgoingBlob(String incomingBlob)
at System.Net.NtlmClient.DoAuthenticate(String challenge, WebRequest webRequest, ICredentials credentials, Boolean preAuthenticate)
at System.Net.NtlmClient.Authenticate(String challenge, WebRequest webrequest, ICredentials credentials)
at System.Net.AuthenticationManager.Authenticate(String challenge, WebRequest request, ICredentials credentials)
at System.Net.AuthenticationState.AttemptAuthenticate(HttpWebRequest httpWebRequest, ICredentials authInfo)
at System.Net.HttpWebRequest.CheckResubmitForAuth()
at System.Net.HttpWebRequest.CheckSubmit(Exception& e)
--- End of inner exception stack trace ---
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.InstallAddIn()
Obviously, I cannot duplicate from my location. My gut is telling me this customer's network security is causing an issue (my understanding is that they have a series of firewalls and such), but their Windows XP machines are having no problem installing.
Anybody see anything I'm missing?
In the end, the answer wasn't too difficult. What was happening is that, obviously, the user is behind a Proxy Server that's blocking the download of the VSTO file, as it didn't have the Proxy Credentials.
So, I've had to make an exception for these users, sending them all the files in a zip that they can install from.
Note that users that run into this MUST run a command to clear the ClickOnce app cache before proceeding; it looks like the mere attempt to install this was leaving some residuals behind that was causing a problem. If you don't already know, you can clear the app cache by running this command from the command prompt (or creating a .bat file containing):
rundll32 dfshim CleanOnlineAppCache
There is a MS KB (KB917952) that corrects ClickOnce deployment issues when using Proxy Authentication.
End users or IT can modify the machine.config to enable proxy authentication with their NTLM login. This will allow them to install ClickOnce or VSTO applications behind proxies that require authentication.
How To: Change your Default Proxy to always use your default credential (NTLM login).
Edit %windir%\Microsoft.NET\Framework\v4.0.30319\config\machine.config
Add the defaultProxy element shown below. Remember to add to an existing system.net section when one exists already.
<configuration>
..
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true"/>
</system.net>
...
</configuration>
Element (Network Settings)
useDefaultCredentials
Specifies whether the default credentials for this host are used to access the web proxy. The default value is false.