Hey guys, I have a VS2005 website project on my dev machine. It compiles and runs perfectly. When I publish the project and put it into production, the Login control keeps giving me a "Login failed for user..." error. The web.config is the same, the connection strings are the same. Anyone know what the problem could be
Login Control problem
Hot Topic
- How can I join two image file into one file?
- how to open an image file(bitmap) in a paint window using c#
- Help me to understand better the interfaces
- Week number of a DateTime value ?
- Is it possible to use variables to specify assembly reference paths?
- How do you cast an object to a ComboBox Item to Select it....
- C# Needs a Property keyword like MC++ has now
- Resizing jpg to smaller resolution
- Pass by Whatever
- strange performace question, maybe a bug?
Visual C#
- Why is the C# team allowing this to Happen? and Why do they close threads on the topic?
- Printing the contents of a RichTextBox
- how to get object instance dynamically?
- Generics & Type Casting
- Possible to disable Control-Alt-Delete buttons?
- calling C++ methods from C# and vice versa
- please microsoft or anyone tell me why !!!????
- How to determine file reading progress
- Multiple user controls
- Designer can't process code, new build errors
Login Control problem
kowalsky
Well, unless you were pointing to the production database while you were testing, you did change something fairly significant. It might seem obvious, but you're sure that the credentials you're using are in the production database And the password hasn't changed Is the password hashed If so, which algorithm is it using
Would it be possible to run your tests against the production database Or perhaps you could use SQL Profiler against your test data source and see if the same queries run against the production database provide different results.
Phil Seastrand
Visio User
Yes, but the built-in Login Control uses a membership provider to determine which credentials are valid and which are not. Which provider are you using Does the production server have access to the same data store as your test server when it comes to validation
Kandikan
I created a provider using the following:
<membership defaultProvider="DefaultProvider">
<providers>
<add connectionStringName="IBConnString" minRequiredPasswordLength="5"
minRequiredNonalphanumericCharacters="0" name="DefaultProvider"
type="System.Web.Security.SqlMembershipProvider" />
</providers>
</membership>
And in the login control I specify this: MembershipProvider="DefaultProvider"
The connection string is pointing to the production DB. So I don't change anything when pushing to production. All the other data access works fine on both servers, it is just this Login control that is giving me issues.
iHEARTmicrosoft_BUT
Yes. My hunch says that the user id under which your production system is running doesn't have access to the database that contains the credentials. What does the connection string look like Does it include a user id and password or are you using integrated security
Ensynch
I am pointing to the exact same database while testing. I know the credentials are in the production DB because I am testing with the production DB. The only difference is where the site is hosted. On my development machine it works fine. On the production server(which also hosts the production db), gives me that issue.
I will run profiler against it to see what I can find.
uconnbizniss
Bruce Sandeman
Yea that's what I thought, so I created a test app pool that runs as the local system, which has administrative rights, and it still didn't work.
And also, if that was the issue, then my data access throughout the site wouldn't work, but it does. The only issue is the login control. I tested using the dbo account, and I have the aspnet tables inside of the main database for the website. The server is 2003 Server, the test machines are Xp Pro. I ran profiler and noticed it -is- running a query against the correct database/tables when on the server, but for some reason it says login failed.
Going to pull my hair out. Or just go back to traditional user/roles authorization.
dydoria
The connection string contains the username/password.
The thing that gets me is that it works under the Vs2005 built in web server, but not IIS, using the same machine.
Scott Berry
Debasish Bose
What mechanism are you using the validate the user's credentials
Craig Shaughnessy
Can you provide more info on this, may be some tracing/event logging would help in here to diagnose further.
-Jay
Shreveport
That screams a permission problem. Keep in mind that IIS runs under a different security context (by default) than Cassini (the Visual Studio Web server) does. The fact that you're using a userid and password in the connection string makes that a little strange, but the different users is basically the only difference between the two scenarios.