Re: Using UserController from Outside HttpContext

xzg3 — Thu, 10 Nov 2005 03:41:58 GMT

Hey Brendan, I'd like to know more about this too. Decoupling the DNN core from HTTPContext seems like a good thing to me....

Thanks,
Josh

Re: Using UserController from Outside HttpContext

brendanrichards — Thu, 15 Sep 2005 22:37:25 GMT

As far as I can tell a user only ever belongs to one portal (Except the superuser) - a user's portal id is stored in UserInfo.PortalId.

Re: Using UserController from Outside HttpContext

rodneyjoyce — Thu, 15 Sep 2005 07:54:38 GMT

Thanks for sharing Brendan.

My knowledge of this area is a bit sparse - I use the scheduler to send out birthday emails for my UserProfile module - can you explain how the scheduler will know what Portal a user belongs to? Does your code handle multiple portals?

Using UserController from Outside HttpContext

brendanrichards — Thu, 15 Sep 2005 05:20:17 GMT

Hi,

I've had a specific problem with the UserController / DNNMembership provider code which I've found a work-around to so I'm posting my solution in case anyone else finds it useful or can point out any problems in my thinking...

First a bit of background:

My website solution using DotNetNuke required an daily user-import process to import users from external data. This process runs under the DNN webapp within its own Thread so that you can set it running via a web interface but not have to wait for it to complete before viewing the next screen (which in this case is a little web control that displays a progress report for the running import process).

The problem with this approach was that DNNSQLMembership provider (and other similar providers such as DNNSQLRoleProvider etc) use the HTTPContext.Current object to store an "ApplicationName" property:

HttpContext.Current.Items("ApplicationName") = ApplicationName

When called from a Thread other than within a Request/Response, HTTPContext.Current is null which meant that the UserController.AddUser was throwing a null object exception when called from my import process Thread.

My fix is to add a null-check and then use a "ThreadLocal " [java terminology ;-) ] property if HTTPContext.Current is null

So the Set function of DNNSQLProvider.ApplicationName() becomes:

Set(ByVal Value As String)
                If (HttpContext.Current Is Nothing) Then
                    System.Threading.Thread.SetData(System.Threading.Thread.GetNamedDataSlot("ApplicationName"), ApplicationName)
                Else
                    HttpContext.Current.Items("ApplicationName") = ApplicationName
                End If
End Set

This works by attaching the value to the local Thread rather than HTTPContext.
I applied this approach wherever I found HttpContext.Current.Items("ApplicationName") in the DNN Solution and can now modify users from my Thread.

I suspect this fix may be useful to anyone who intends to modify users from the DNNScheduler.

hope someone finds this useful - If so, I can provide more details...

Brendan.