We have web application designed in VS2008. When adding some new functionality we are trying to use Web API.
In the existing system, each user from a client has access to their database. So, when a user logs in, we pull the connection string and save it in a session. Every insert, Update or select that the user performs, it uses the connection string in the session and when the user logs out, it gets cleared out.
How do I achieve this functionality if I have to use a Web API in this scenario?
Can I pass the connection string to Web API for every request?
The only other way I could think of is after every request to Web API, I have to connect to database and get the connection string based on the UserID that I have. This would add one extra step of connecting to database for every request.
Is there any other way?
Thanks in Advance
Related
Is it possible to allow a client connect to a database (E.g. with Excel) via a WebPage? The WebPage acts like a proxy and handles the user connection to the DB? The user can then query the DB with their client app.
I have never heard of a way of achieving this, but a colleague mentioned it was possible in ASP.NET.
Here is the scenario. The database server DBServer (SQL Server 2008) is on box 1 and the web server running an ASP.NET application is on box 2 (IIS 7.5).
The ASP.NET is using windows authentication so that all domain users are able to log in to the application using their windows credentials.
I am trying to get the name of the user who logged on the ASP.NET in DBServer. There is a trigger on each of DBServer's tables to audit the user who updates or inserts data, and currently that user name is retrieve by this:
select SYSTEM_USER
However, this statement always returns the name of the DBServer rather than the logged on user.
I have also tried several other possible solutions:
Enable the Impersonate. However, "select SYSTEM_USER" always returns impersonated user's name.
Run the ASP.NET application as a specific identity in application pool. Still, "select SYSTEM_USER" returns the identity's name.
It seems to me there is no way to get the logged on user name for this situation. Any idea?
Thanks in advance!
As a workaround, perhaps you could pass the Windows username into your stored procedures (assuming you are controlling data access via stored procedures). Or you could pass it in via the connection string using a "thwartable" property like Application Name... when a user logs into the app, have their session build & use a connection string dedicated to them, e.g.
...;Initial Catalog=dbname;Application Name=<inject login name here>;...
Now you can pick this data up by session_id from sys.dm_exec_sessions.program_name.
As a caveat, this means you can no longer identify the application through this property. If you want to continue doing this, you could decide to stuff both the app name and the login name into this property and split it out when doing the auditing. This way you can still have traces etc. identify the web app by using like instead of =.
(Note that this column is limited to 128 characters.)
I am sure there is a way to set IIS to pass your credentials onto SQL Server, I just haven't done it. You may want to look into this article.
I cannot connect to my SQL Server database when running app on server.
Everything runs fine when debugging but when I run on the server as ASPNET the user is unable to login.
I created the dataabse in a test project then simply connected to this db. My connection string is
Data Source=.\SQLEXPRESS;AttachDbFilename=C:\Temp\Barry\fsr\FSR.mdf;
Integrated Security=True;Connect Timeout=30;User Instance=True
So this asp app runs on IIS 5 and when deployed the initial select works fine as my gridview that I have a binding to shows data but when I run the program (update the db) I hit the following:
[SqlException (0x80131904): Cannot open user default database.
Login failed.
Login failed for user 'hostxxxxx\ASPNET'.]
I am not creating this database programmatically as mentioned previously, simply connecting to an existing database.
The database is located on my c: - but I have added user ASPNET. How can I add this db to the program as a resource rather than reference a copy on c:?
My first question is this: If you have control of the server, why are you using an attached database. From:
AttachDbFilename=C:\Temp\Barry\fsr\FSR.mdf
There is no reason to attach if you can control the server. Attach the database to the actual instance in SQL Server, not with the bastardized version you have above. The bastardized version is useful on an ISP that does not give you access to SQL tools. Beyond that, it is more work than it is worth.
The second problem you have is authentication. There are a couple of ways to handle this. The easiest is set up a SQL user to access the database. If every user will have login credentials, you can keep the Windows Authentication method, but you have to turn off anonymous access, so every user GETS authenticated. As long as anon is a choice in IIS, it will default to anon and you will have issues. The third way is to impersonate a user for database access. I guess the fourth is open your database wide open, but I don't suggest destruction of security to make something "work".
If you have your database on a server, you need to use a server-based connection string - something like:
Data Source=servername\SQLEXPRESS;database=FSR;
Integrated Security=True;Connect Timeout=30;
Your user needs to have a login on the server, and a user in the appropriate database, in order to connect successfully.
See the ConnectionStrings.com web site for a huge list of possible connection strings - and what their settings mean and how you can change those.
You need to get into your database and assign the proper privileges to the account that is trying to access the database, which in this case looks like the built-in ASPNET account. Instead of the ASPNET account, you should use the NETWORK SERVICE account. You can change this through IIS.
I'm developing a site that will display confidential readonly information,
with data fetched from a WCF service.
My question:
What is the best approach to user management across different information pages.
The service returns a collection with customer info after a secure login.
My idea is to have a Customer object class that is stored in session.
Is it possible to use things like HttpContext.Current.User.Identity.IsAuthenticated
followed by HttpContext.Current.Session["UserId"] without using a database with role-based security?
Would I be better off with a combination of local database, Linq to SQL or datasets rather than using
just class objects for data fetched from service?
thanks,
nakori
If you have no need of tracking the user's identity within your application, just use session as you indicated.
But the HttpContext.Current.User.Identity.IsAuthenticated and such relies on the user having authenticated with your site in some way or another (or it will always come back as false). Authenticating with the web site doesn't necessarily need a database though. You can setup users directly in web.config, xml files, or use AD or some other authentication mechanism that doesn't use a traditional database.
But unless you need to authenticate the users, you can probably do what you want using the server's session object and/or cookies.
You don't need a local database - but best practice is to have the user authenticate. The two options are via a database and or via AD if this is an internal site.
You might as well create a new WCF service to perform the authentication since you've already got your database functionality separate. This will also let you access databases that aren't local.
The first time I log onto my webservice I want to use FormsAuthentication e.g.
myService.ClientCredentials.UserName.UserName = "name";
myService.ClientCredentials.UserName.Password = "password";
but once a user has logged onto my web app I dont want to have to know about his password so I would like to be able to connect to the webservice as this user without knowing his password. Is this possible?
I would save the password on whatever front end is accessing the web service and then pass it behind the scenes whenever the user called the web service.
So essentially, design your web service take a password always, but have the front end cache the password so once the user enters the password, the front end doesn't ask again.
Be forewarned, there may be a security concern with keeping the password cached, as I believe that would be part of the session. I'm not familiar with how .net handles this, but you may want to look into hashing.
You should be able to do this, but there are several issues to consider. Forms-based Authentication (FBA) normally uses a cookie to track authentication.
Security - Configure the web application
and web service to use the same FBA database.
Domain - As long as the web service
is on the same domain as the web
application, the web service can use
the same authentication cookie. If the
client has cookies disabled, then this
may not work.
Cookie expiration - You need to configure
the duration of the authentication to an
acceptable time limit (30 minutes, 1 hour,
1 day, or more) in the web.config file. This
will allow the user to access the web service
within a proper time frame after he or she
has logged in.
you can enable sessions in your webservice. There is a simple token that you add in at the begining of the service declaration.
<WebMethod(True)> Method Name