Last post Feb 12, 2007 11:52 PM by Russ Helfand
Feb 08, 2007 08:05 AM|m_judd|LINK
if (Membership.GetUser() == null)
Feb 08, 2007 07:46 PM|Rasetti|LINK
Your scenario doesn't seem to be very clear. You were not using Membership but you need it? The change between the regular login control and the adapted one caused the problem, and, therefore, you stopped using Membership? If you are not using membership
in your app, how do you authenticate the users? Are you using a custom database and authentication logic to set the authenication cookie?
If you use the OnAuthenticate event to get your "user" from the membership provider you should use Membership.GetUser(Login1.UserName, True) instead of Membership.GetUser(). You can find in the forum a lot of posts explaining why. After the authentication
process is completed and the user is redirected to whatever page is defined, you can use the HttpContext class to retrieve some session properties, including if the user is authenticated, avoiding making calls to the Membership provider.
Otherwise, you should explain further your scenario, tell us how you are authenticating the users instead of using the MembershipProvider, for us to be able to help regarding any "potential problem that could happen in the future"
Feb 09, 2007 02:06 PM|m_judd|LINK
Hi Juan - apologies for not making myself clear.
I'm using the Login control and I handle it's Authenticate event by checking the users details against a database (i.e. I am NOT using any MembershipProvider). In my OnAuthenticate handler,
I set the Authenticated property of the event to True. I also use a LoginStatus control to show different information when the user is logged in and logged out.
All of the above was working perfectly.
My problem arose when I started to use the CSS Friendly Adapters. The LoginStatus control stopped working for me and I worked out that this was because the LoginStatusAdapter was using the
Membership.GetUser() method to determine whether a user is logged in or not. I am not using any MembershipProvider so this call failed.
I think that this could be considered a bug and that the LoginStatusAdapter should use this.Page.Request.IsAuthenticated to determine whether the user is logged in or not rather than Membership.GetUser().
I have made the change to do this in my copy of the LoginStatusAdapter and it seems to be working well.
All I was asking (albeit not very clearly, I admit!) was whether anyone else thought that this was not a good thing to do.
Feb 09, 2007 03:45 PM|Russ Helfand|LINK
Hi Juan and M_Judd,
I'd like to stick my big nose into this discussion. I hope you don't mind.
First, let me say that the work-around suggested by M_Judd looks plausible and OK to me. So I think it's safe to us. And, I can use it in the next version of the kit if we can't otherwise sort out why the original code isn't working well. That brings up
what I want to tackle: why isn't the original code working?
The Membership class has a static method called GetUser that is supposed to return a user or null depending on whether or not anyone is logged in. That is supposed to work regardless of whether or not you've replaced the default membership provider with
a new one in your web.config. Remember that even if you don't set up your own membership provider you are still configured (by default) to use a membership provider (via the machine.config defaults). So the problem isn't that there isn't a membership provider.
Instead, the problem appears to be that the GetUser method in the membership provider that is being used freaking out.
Now I need to work with you to figure out why that's happening!
It would help to know:
1) What is the exact error being reported when you don't have a custom memberhsip provider and are using the original code. You said there was a problem but you didn't give the exact details of the problem (including error messages, etc.). Those details
2) Are you sure that you haven't inadvertantly set up a membership provider (other than the default) or removed the default membership provider in any of your web.config (or machine.config) files?
Thanks for helping me diagnose this further. Cheers.
Feb 11, 2007 03:06 PM|m_judd|LINK
When I originally used the CSS adapters, I didn't have a <membership> section defined in my web applications Web.config. In this case, I saw the error below when the LoginStatusAdapter ran after a user was logged in to the site:
Exception type: HttpException
Exception message: Unable to connect to SQL Server database.
Stack trace: at System.Web.Management.SqlServices.GetSqlConnection(String server, String user, String password, Boolean trusted, String connectionString)
at System.Web.Management.SqlServices.SetupApplicationServices(String server, String user, String password, Boolean trusted, String connectionString, String database, String dbFileName, SqlFeatures features, Boolean install)
at System.Web.Management.SqlServices.Install(String database, String dbFileName, String connectionString)
at System.Web.DataAccess.SqlConnectionHelper.CreateMdfFile(String fullFileName, String dataDir, String connectionString)
This is because ASP.Net is trying to connect to the default MembershipProvider (AspNetSqlMembershipProvider) which was not set-up.
I didn't like the idea that ASP.Net was doing this so I added the following section to my web.config to remove the default MembershipProvider:
<remove name="AspNetSqlMembershipProvider" />
Exception type: ProviderException
Exception message: Default Membership Provider must be specified.
Stack trace: at System.Web.Security.Membership.Initialize()
at System.Web.Security.Membership.GetUser(String username, Boolean userIsOnline)
at CSSFriendly.LoginStatusAdapter.RenderContents(HtmlTextWriter writer) in d:\WebApp\App_Code\Adapters\LoginStatusAdapter.cs:line 76
at System.Web.UI.WebControls.Adapters.WebControlAdapter.Render(HtmlTextWriter writer)
I found that the change I mentioned earlier in this thread allowed me to use the LoginStatusAdapter with the default in either of these scenarios without error.
Hope this helps!
Feb 11, 2007 03:17 PM|rdahbura|LINK
I agree 100% with the workaround being proposed, as per the following MSDN excerpt:
"The LoginStatus control has two states, logged in to the Web site and logged out of the Web site, determined by the
IsAuthenticated property of the
Request property." -
So the CSS adapter class seems to deviate by using Membership.GetUser() in that particular control (unless there's another intent that I'm just completely missing).
I went ahead and changed my CSS adapter source code and recompiled and now the control works as the non-CSS control did.
Let me know your thoughts.
Feb 11, 2007 06:04 PM|Rasetti|LINK
I've run into the same problem m_judd is having now some time ago, and then I found that, during the login process, the static Membership.GetUser() returns nothing, even after the authentication has been performed. Only when the page is redirected after the
login you can use that method.
So I changed the adapter's code to Membership.GetUser(Login.UserName) on the authentication process to retrieve information about the user, and it's working ok so far.
Thanks for the clarification! As I said, i'm using a different approach to get the same result. Membership.GetUser() throws an error using the adapter, as the other posters are saying it may be safe to use your approach, but you may also want to try to modifi
the adapter code and use Membership.GetUser(Legin.UserName) instead.
Feb 12, 2007 11:52 PM|Russ Helfand|LINK