Reference the UserId value in the Add WHERE Clause dialog?

hoss · February 18th, 2011, 03:58 PM

I've not been able to find much of anything on this seemingly basic question via google. Your book does not try to do this, exactly, but I hope you don't mind my asking about it here.

On page 401 the Add WHERE Clause dialog is shown and you show how to reference a control for the where param.

I want to do something a bit different. Using the asp.net membership framework, after a use has logged in, we should be able to use the UserId value for the current user a query param. For example, if I wanted to show the user's aspnet_Users row in a datagrid, I'd apply the param to UserId. But I can't find a way to directly reference the current user's UserId value there. The dialog's Source drop down list includes Profile, but that's not really the right table (it's probably aspnet_Profile). I've tried setting Source to "Session" and the param to "UserID" but no luck.

I found an article on the net that says there is no direct way to reference the current user's UserId value in this Add WHERE Clause dialog (the article also provides a workaround), but the article was for asp.net 2, and it just seems odd that such a basic capability wouldn't be there out of the box.

If I figure this out on my own I'll post back here.

Imar · February 18th, 2011, 04:10 PM

Hi there,

You can create a generic parameter and then use the control's Selecting event to assign a value as explained in one of my posts in this thread: Displaying data based on user logged in

Cheers,

Imar

hoss · February 18th, 2011, 04:18 PM

Yes, that's just like the solution I found in an article 'out there'. It just seemed kind of odd to me that the most fundamental identifier for the logged in user wouldn't be drop dead simple to access via that WHERE wizard. But I guess some code is required, no big deal.

Thanks again Imar

Imar · February 18th, 2011, 04:40 PM

I think it depends on how you look at it. Membership is "just a feature" in ASP.NET which you don't have to use in every site. I think it's not generic enough to warrant its own place in the wizard. Somebody else might need the current user's roles, another today's date and yet another the path of the currently requested file. From the view of a DataSource, these are just "random" properties of other objects available in the huge .NET Framework.

I think Microsoft decided to not develop each and every possible combination of values, but instead provided a generic mechanism you can use for any kind of data.

That said, I agree that it would be useful and a lot easier if there *was* a Membership option in that list ;-)

Cheers,

Imar

hoss · February 18th, 2011, 10:19 PM

If you don't mind an architectural question, again not really directly related to your excellent book.

I'm putting together a test of a multi-tennant website where almost all of the content will be constrained by two factors - the user's role per the asp.net membership framework (say siteadmin, groupadmin, groupuser in desc order of capabilities) and whatever groups they may belong to. A "Group" would be a subset of users have have joined to utilize the site's feature around a certain topic space, example one group would be about New York and another group would be about Stockholm.

Thus as the user navigates around the site, something must be referenced in order to filter the data that is shown to the user. Example if they go to the My Groups page they'd see just the groups they were members of, and if their role was GroupAdmin they'd see some extra stuff for managing groups.

What's the best way to keep track of the user's identity, role, and membership? Should one utilize the UserId code we just discussed for each sqldatasource, or is it better to use session variables?

I'm sort of hopping around in the book...I don't see very much about sessions in the index.

Imar · February 19th, 2011, 04:32 AM

It's OK to use the UserId for that. Sessions may expire while the user may still be logged in to the system. So, by using the UserId you may end up with a more robust system.

BTW, Microsoft recommends to not use the UserId as it's an internal implementation and not guaranteed to be there forever. Instead, they recommend to use a combination of the UserName and the name of the application.

This is a bit more work, and the chances of the ID ever getting removed are small if you ask me, so you might as well stick to the UserId. Just don't blame me if it *does* break in the future. ;-)

For future posts like these, can you please choose a more general .NET category? This isn't really related to the book and makes things harder to track and find.

Cheers,

Imar