Hey guys,

I added the RSS Toolkit to the site. It worked perfectly as far as displaying feeds, but now no one can login. The logins aren't passing authentication. The weird thing is that new accounts that have been created since then DO work. I feel it was something that was changed in the web.config.

Here are the entries that were added:

<system.web>
        <compilation debug="true">
            <assemblies>
                <add assembly="RssToolkit,Version=1.0.0.1,Culture=neutr al,PublicKeyToken=02e47a85b237026a"/>
                <add assembly="System.Design, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
                <add assembly="System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
            </assemblies>

            <buildProviders>
                <add extension=".rss" type="RssToolkit.RssBuildProvider,RssToolkit,Versi on=1.0.0.1,Culture=neutral,PublicKeyToken=02e47a85 b237026a"/>
                <add extension=".rssdl" type="RssToolkit.RssdlBuildProvider,RssToolkit,Ver sion=1.0.0.1,Culture=neutral,PublicKeyToken=02e47a 85b237026a"/>
            </buildProviders>
        </compilation>
    </system.web>

    <appSettings>
        <add key="defaultRssTtl" value="10"/>

    </appSettings>

    <system.net>
        <defaultProxy useDefaultCredentials="true"/>
    </system.net>


Any idea what would be causing this?
Thanks!

Link to RSS Toolkit: http://blogs.msdn.com/dmitryr/archiv...26/561200.aspx

It could have something to do with the RSS Toolkit, but I doubt it.

Check your aspnet_Applications table. I will bet anything you have more than one app in there. This would normally be caused by moving the application to a different server (i.e., from a test to a production server, or even maybe from the internal Cassini server to a virtual directory in IIS) and failing to specify an applicationName in your authentication config.

You're right, there are two applications listed in there. Except that the correct App is named as the applicationName and the site has been working in the same environment (discountasp.net) for over a year with those same settings. I rolled back my web.config and all other pages I've made changes to in the last few weeks and it's still not authenticating users. This problem just came up over the weekend. All the hashes for the passwords and salts in the database are the same as they ever were so I'm having a hard time figuring out what is causing the problem. Also, the password retrieval isn't working either, you just get "We were unable to access your information. Please try again." after searching for the username.

It's likely that discountasp.net moved the app to a new server without your knowledge. I am pretty sure this is what is causing your problem.

Look at your <membership> section in web.config. I am willing to bet you do not have an applicationName= in there.

By failing to include an application name in your membership provider, ASP.NET has automatically set up an application name for each server this application has been run on. The problem with that is, that all logins set up on the old server will not work on the new server (and or course, logins set up on the new server won't work if you move it back).

(This is not your fault. You should always indicate an applicationName for all providers, but the book fails to follow this best practice. If you had done that, this wouldn't have happened.)

What you need to do is to fix this is to open aspnet_Users and aspnet_Applications, and try to figure out what application name and id was in use when the old logins were created. You can do this by looking for an "old" login, and matching up the ApplicationID field with the ApplicationID field in the aspnet_Applications table. This will give you your original application id and name.

Then, you need to go to web.config and put the original application name you found in the Membership provider: applicationName="/blahblah". That will assure that new logins created from that point forward will work.

Finally, you have to migrate all the "new" logins to work with the original application id. Copy the original application id to the clipboard, then by hand find each "new" user in aspnet_Users and the corresponding entry in aspnet_Membership, and paste the original application id from the clipboard to the ApplicationId field in both tables for each record you need to "fix". This is kind of tedious, so hopefully you won't have too many.

Hope this helps...

Lee

Thanks for the detailed help Lee!

I've got a few accounts back to normal, now I've just gotta crunch the last 80 or so and we're good to go. Thanks again!

Yes, you're welcome. I discovered this one the hard way, just like everyone else!