Every password that i enter and when i click the button, it tells me that the password is wrong. it activates this field in its properties: InvalidPasswordErrorMessage.
I suspect that the user tries to use the password to connect to the database.
Another weird thing, is even when a password fails to be created..(invalid), the control stores the record in the database... for example in the PasswordFailed in the members table, i get a date and the users details (The control did it in a few occassions, which is bad for login)..
The main issue however, is with the password always being invalid..
In the membership configuration you will find attributes for setting minimum number of non alpanumeric characters, min length etc. Try lowering all such values and see if it accepts your passwords. A complex password like "abc%12U8" should also be accepted.
But the error message also displays upon db connection errors so you should test the connection to the database.
also the db identity should be a member of all the "aspnet_.*" roles on the database.
Related
I have an ASP.NET (C#) web application that connects to Informix 12.x database. The web application uses a database connection string with username and password. Users are given login accounts to use the web application and they can delete records in the database.
The database tables have "LastModifiedBy" which contains the user ID. Now, I need to implement auditing using database triggers. I need to capture what records were updated or deleted and who did it (i.e. logged in user) and save these in an audit table.
For the delete trigger, how can I capture the user ID of the logged in user and save this in the audit table?
The database user (available via the keyword USER) is always going to be the username associated with the shared database credentials. Your question is not very clear, but are you saying the existing LastModifiedBy attribute contains the named user or the database user? If it's the named user, I think you should probably look at your ASP.NET code to see how that gets passed into the UPDATE statement.
I'm no expert on ASP.NET, but assuming a single page request uses the same database connection throughout its processing cycle, then you could maintain a table keyed on the session ID, available via DBINFO('sessionid'), where you capture the named user at the top of the request, and then you have it available at any point throughout the process for inclusion in your audit. But if the web-server processes are using a pool of database connections and any statement could go to a different connection, even that won't work.
Ultimately, I don't think database triggers are the right solution here, not least because you'll have to write and maintain a trigger for every table in your application. If I was faced with this problem I would be more inclined to have a common Audit function within the web-app, where the named user is always available.
At the OP's request, a bit more detail. The Session ID is exactly the same concept as you see in SSMS - just a unique number that identifies the connection.
Imagine you have the following table and procedures:
CREATE TABLE session_user (
sessionid INTEGER NOT NULL,
username VARCHAR(20),
conn_date DATE,
PRIMARY KEY (sessionid)
);
CREATE PROCEDURE set_user(v_username VARCHAR(20))
UPDATE session_user SET username = v_username, conn_date = TODAY
WHERE sessionid = DBINFO('sessionid');
IF DBINFO('sqlca.sqlerrd2') = 0 THEN
INSERT INTO session_user VALUES (DBINFO('sessionid'), v_username, TODAY);
END PROCEDURE;
CREATE PROCEDURE get_user()
DEFINE v_username VARCHAR(20);
SELECT username INTO v_username
FROM session_user
WHERE sessionid = DBINFO('sessionid');
IF v_username IS NULL THEN
LET v_username = USER;
-- return system user if no record found in session_user table
END IF;
RETURN v_username;
END PROCEDURE;
NB: None of this code is tested, it's just to show the principle. I don't have an Informix instance to hand to test this on.
At the top of the request, however you execute your SQL, you would run:
EXECUTE PROCEDURE set_user($the_web_user);
Your triggers could then use get_user() wherever you want to capture that info. You'll get the actual web user if it's been recorded in the session_user table, otherwise the database user (which will be the shared database credentials if the triggering DML has come from the web-app, or the physically logged in user if the trigger is via a DB-Access session).
I still don't think this is a particularly maintainable solution - every table needs its own trigger(s). An OO audit method in the web-app would be a more DRY approach, or have a look at Informix's preexisting audit capabilities.
Note: the date field was included in the session_user table so you run a clean-up over it, because depending on how often new connections get created by the web-app, your session_user table could grow like topsy.
I need to check how many invalid attempt a user taken at the time of log in.
This is becauase our requirement is to save the max attempt password value from db not config.
The default Membership API doesn't expose the invalid attempt counts, but they are indeed tracked in the database.
If you take a look at the documentation for the Sample Membership Provider Implementation you'll see the following in the Database schema section:
FailedPasswordAttemptCount Integer,
FailedPasswordAttemptWindowStart DateTime,
FailedPasswordAnswerAttemptCount Integer,
FailedPasswordAnswerAttemptWindowStart DateTime
These work in conjunction with the PasswordAttemptWindow setting to lock users out if they fail to supply the correct values, and the counts are updated by the default provider when the user fails to log in.
If you want to manage these through a database rather than the web.config you only really have one choice: Write a custom membership provider (based on the sample) that reads the required values from the DB rather than the config settings.
This is because the property on the provider is read-only so you can't modify it once the provider is loaded and instantiated.
I've specified the user of my application pool to be SERVER4\IUSR_SERVER4. And then I added this user to the SQL Server. But when I try to connect to the database I get the following error:
Server Error in '/BSHHD' Application.
Cannot open user default database. Login failed.
Login failed for user 'SERVER4\Administrator'.
What's driving me mad is there's no user named SERVER4\Administrator. What do I have to do in order to be able to properly connect to this SQL Server database from my website?
P.S. I think this is related with Membership authentication. Now I need to find out how Membership accesses SQL Server and where the login credentials are specified
The thing is, the app pool user is not necessarily the user you use to connect to MSSQL (as a guy in the comments already stated). After seeing your connection string, this is probably the case, and maybe, just maybe, the problem is not the user but it's default database.
I've had this error in the past: Try setting the user you use in the connection string (clerk's) default database to something else. This error is common when you've set a default database for a user before and now the database doesn't exist anymore or is having some problems.
You can change the user's default database using something like this:
Exec sp_defaultdb #loginame='clerk', #defdb='dok'
You can also use something like this but I've never used it:
ALTER LOGIN SQLLogin WITH DEFAULT_DATABASE = AvailDBName
Also, there's no need to set the integrated security to false because it is the default value already. I hope this helps =)
I have a reportviewer (Microsoft.ReportViewer.WebForms) control on my page. All my reports use one data source. I want to be able to let my reports run on a different database when started from my UAT enviroment. So the location of the reports is the same, but the data comes from a different db. I cannot seem to find how this is done, is it even possible?
EDIT: They are server reports on SQL Server . I know you can set the dataset programmaticaly but I just want the reports to point to a different db and leave the rest of the report intact.
2005
TIA,
John
Did you want to pass a full connection string to the report as a parameter? You can do it but sometimes SSRS gets funny and make sure you delete the report off the server before you deploy a new copy when doing this...
1. Make a parameter - let's call ours connectionStr. Make it not null, not blank, single select and text as the data type. Eventually, you will want to hide this parameter but for testing please leave it visible.
2. So the value you will be using as the connection string... (for testing I set this as the default for the parameter, with nothing put under the available values section) Data Source=MySQLServerName;Initial Catalog=MyDatabaseName;Persist Security Info=True;User ID=MyUserNameForTheServer;Password=MyPasswordForTheServer;MultipleActiveResultSets=True
3. You need an unattended execution account on your report server or you get this: unattended execution account is not specified. (rsInvalidDataSourceCredentialSetting). http://msdn.microsoft.com/en-us/library/ms156302.aspx I can't provide more details because my boss had to do this part for me.
4. Under your datasource properties in SSRS... check Embedded Connection, select the type (mine is just a normal MS SQL Server), for the connection string, open the expression box and put: =Parameters!connectionStr.value and then click credentials and make sure the last option for no credentials is selected.
5. Your datasets for that datasource will no longer be happy when you try to edit them in design view but you can switch the datasource connection properties back to how they were, not using the parameter based connection string, for editing them.
My reports are on different servers, with different instances of the Report Server, too. On some servers, they need to get their data from various databases depending on whatever, stuff. This way, with the connection string as a parameter, I can use the same reports everywhere and just deploy them to the different servers. If you are having to pass this connection string around your app or to a report viewer, I suggest using encryption.
Like I said... SSRS get's funny when you start doing this, though. Your reports should always work in preview mode after doing this, if they don't even when provided with the correct connection strings, then you have an issue that won't be solved by just deploying to the server. Trouble shooting problems with this once they are on the server but not working include checking permissions, making sure the report receives the correct connection string and making all your stored procedures and functions within the SQL database are all the same.
If you want to just pass the database name and everything else is the same (server name, username, password) then just set the connection string parameter equal to your database name and for the datasource expression value use
="Data Source=MySQLServerName;Initial Catalog=" + Parameters!connectionString.value + ";Persist Security Info=True;User ID=MyUserNameForTheServer;Password=MyPasswordForTheServer;MultipleActiveResultSets=True"
I needed to pass the whole thing in, and you can play around with the credential settings - you might be able to save the server username/password info in there for each report so that the unattended execution account is not needed.
If I call user.ChangePassword(oldpass,newpass), and the old password is wrong, or the new password does not meet the provider's complexity requirement , the method fails without warning. is there any way i can find out if there is an error and what the error was.
I can always put these checks in my code, but there should be a way to do it using the Membership APIs
Unfortunately not. The ChangePassword method only returns a simple bool for success/fail.
Your best option on fail would be to display a generic message to the user stating all possible failure reasons... e.g.
Failed to Change Password.
This may have occured because:
The Old Password was incorrect
The New Password failed to meet the required complexibility
New Passwords must be 8 chars long and contain at least 2 numeric characters. (or whatever)
If you want to give more specific information, then as you said, you would need to implement a rules checker in your own code and relay information to the user based on that check.