Devart Forums

We have a web app working fine in a production server. We have developed a new version of such web app and we are trying to bring the users from the old app to the new app. For this purpose, we did the following:

1) We exported the required membership tables from the old web app (aspnet_users, aspnet_membership, aspnet_roles and aspnet_usersinroles)to text files delimited by TABS.
2) We imported the text files generated in step (1) to the new web app tables.
3) We used a tool called PostgreSQL Maestro to achieve steps (1) and (2).
4) The aspnet_membership table in the new web app has 2 fields that are not present in the old web app table: "passwordsalt" and "passwordformat".
5) We replaced the "passwordformat" field value with 2 which indicates ENCRYPTED, we do not use TEXT or HASH format.
6) We left the value of the "passwordsalt" field equal to NULL.
7) The old web app uses the following tool versions: DevArt v5.50.228.0 and .Net Framework 3.5.
8) The new web app uses the following tool versions: DevArt v6.0.6.0 and .Net Framework 4.0.
9) The parameters of "machineKey" entry in web.config of the new web app are exactly the same as in the old web app.
10) The provider parameters in the old web app have a difference with those in the new web; the new app includes applicationName="/" whereas the old one does not.

Old web app:
<add name="AspNetPgSqlMembershipProvider" type="Devart.Data.PostgreSql.Web.Providers.PgSqlMembershipProvider" description="dotConnect for PostreSQL membership provider" connectionStringName="restaurantConnString" passwordFormat="Encrypted" enablePasswordRetrieval="true" minRequiredPasswordLength="7" requiresQuestionAndAnswer="true" requiresUniqueEmail="false" maxInvalidPasswordAttempts="99" passwordAttemptWindow="5" minRequiredNonalphanumericCharacters="0" />

New web app:
<add name="AspNetPgSqlMembershipProvider" type="Usuarios" description="dotConnect for PostreSQL membership provider" connectionStringName="eUsuarioConnString" passwordFormat="Encrypted" enablePasswordRetrieval="true" minRequiredPasswordLength="7" requiresQuestionAndAnswer="false" requiresUniqueEmail="false" maxInvalidPasswordAttempts="99" passwordAttemptWindow="5" minRequiredNonalphanumericCharacters="0" applicationName="/" />

We will very much appreciate any comment about this issue. Below we include the error message text for your reference when trying to validate user credentials:

Provider can not decode password

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Configuration.Provider.ProviderException: Provider can not decode password

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:


[ProviderException: Provider can not decode password]
Devart.Common.Web.Providers.DbMembershipProvider.a(String A_0, MembershipPasswordFormat A_1) +172
Devart.Common.Web.Providers.DbMembershipProvider.a(String A_0, String A_1, MembershipPasswordFormat& A_2, String& A_3) +226
Devart.Common.Web.Providers.DbMembershipProvider.ValidateUser(String username, String password) +49
System.Web.UI.WebControls.Login.AuthenticateUsingMembershipProvider(AuthenticateEventArgs e) +60
System.Web.UI.WebControls.Login.OnAuthenticate(AuthenticateEventArgs e) +129
System.Web.UI.WebControls.Login.AttemptLogin() +127
System.Web.UI.WebControls.Login.OnBubbleEvent(Object source, EventArgs e) +101
System.Web.UI.Control.RaiseBubbleEvent(Object source, EventArgs args) +37
System.Web.UI.WebControls.Button.OnCommand(CommandEventArgs e) +125
System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) +167
System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) +10
System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) +13
System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +36
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +5563

JORGEMAL wrote:4) The aspnet_membership table in the new web app has 2 fields that are not present in the old web app table: "passwordsalt" and "passwordformat".

We implemented support of password salt in ASP.NET membership provider and added two new columns PasswordFormat and PasswordSalt to the aspnet_membership table in dotConnect for Oracle v 5.70.140. As you used dotConnect for Oracle 5.50.228, were these features had not been implemented yet, you should leave these two columns empty.

JORGEMAL wrote:[ProviderException: Provider can not decode password]

This is a known issue. We have fixed the bug with Membership provider compatibility between .NET Framework 2.0 and 4.0 in dotConnect for Oracle 6.30.160. For more information, please refer to http://www.devart.com/dotconnect/oracle ... story.html

You can use the trial version of the latest dotConnect for Oracle 7.7.217 and check the fix of this issue. Download the trial version of dotConnect for Oracle from our website http://www.devart.com/dotconnect/oracle/download.html

I guess there is a misunderstanding because I am not using dotConnect for Oracle as you say in your answer. My question was posted in the "ADO.NET Data Providers / dotConnect for PostgreSQL" forum. I kindly ask you to clarify this situation.

With respect,
Jorge Maldonado

Sorry for misunderstanding, you are right. According to the versions you work with (5.50.228.0 and 6.0.6.0) there shouldn't be any problems with dotConnect for PostgreSQL when switching from ASP.NET 3.5 to ASP.NET 4.0.

We created a ASP.NET 3.5 application. With the help of this application, we created a user using your record for ASP.NET 3.5 ("Old web app") for web.config. Then we created a ASP.NET 4.0 application using the same record for ASP.NET 3.5 to create the Membership provider + applicationName="/".

Thus, we got access in the ASP.NET 4.0 application to the user created by the ASP.NET 3.5 application.

In your application for ASP.NET 4.0, you use another record to create the Membership element, which is:
- type="Usuarios"
- connectionStringName="eUsuarioConnString"
Could you describe the "Usuarios" type you use?

Besides, the issue might be connected with the machineKey element of the web.config file. In .NET Framework 4.0, the default hash algorithm was changed. To validate the existing users successfully, you should add the following to the web.config file (locally for the application, or globally for the framework):
http://stackoverflow.com/questions/2739 ... 0-from-3-5.

Verify the name of your application in the aspnet_Applications database table and specify it explicitly in the applicationName parameter when registering the membership provider: http://weblogs.asp.net/scottgu/archive/ ... iders.aspx

If this doesn't help, then send us the machineKey element, you use in your web.config file.

The entry for "type=Usuarios" is the class that we use to override the "Initialize" event for the membership provider in order to set a connection string different that the default one. We execute the base method and then set the new conenction string.

The name of the application is "/" in all the "aspnet_" tables that have the field "applicationname" although not all of the tables have records. We do not use "aspnet_sitemap", "aspnet_sessions" and "aspnet_personalization". What I just noticed is that the "applicationName" in the "add name" in "web.config" record for the old app is missing, but it is correctly set for the new app. You can see this in the first message I sent in this support post.

I have sent the 2 machineKey entries for your reference. I see that the old app machineKey entry has the "isolateApps" parameter and the new app does not.

Regards.

Thank you for the machineKey entries. We have tested our application with it and reproduced the issue. But this issue does not concern dotConnect for PostgreSQL. If you remove IsolateApps from the validationKey and decryptionKey attributes in your old application, you will get the same exception "Provider can not decode password".

If IsolateApps is used for the validationKey and decryptionKey attributes, then ASP.NET generates an encrypted key using the application id. Then you try to decrypt data using another key, and as a result you get an exception. For more information, please refer to http://msdn.microsoft.com/en-us/library ... 00%29.aspx

Besides, specifying applicationName="/" in the membership definition contributes to reproducing the issue too. In our environment, deleting applicationName="/" in the membership definition for the new application, and adding IsolateApps to the validationKey and decryptionKey attributes of the machineKey element allows getting access to users created in the old application.

Please note that when you deploy the application on another server or IIS, you will not be able to access the old users, as the application id will change.

I very much appreciate your time and kind support. I will now take the necessary steps to get a solution for my issue.

Respectfully,
Jorge Maldonado