Get currently logged in User

Jun 9, 2008 at 9:05 AM
Hi there.

I builta iWeb method that returns UserInfo data from the currently logged-in user.
Unfortunately the User-Information is always empty so I guess there is an an additional twist to make it work with DNN.

I added the standard EnableSession-Attribute but with no avail. Any help is appreciated.

Jun 9, 2008 at 12:07 PM
Web services do not have a "web context" that is created when a person goes to a url that maps to a portal and the person logs in, so you do not have a "logged in user". With IWeb you always have to pass a portal and a userid to use for authentication.
Jun 9, 2008 at 2:22 PM
Actually standard ASP.NET Webservices have access to the Web Session context. I use this feature in a lot ASP.NET projects outside of DotNetNuke.
You can learn more about "EnableSession" here.

DNN has the additional complexity of identifying the right portal instance and so I thought that there is an extra twist to get hold of the right session context.
I will try to work around this and pass the authentication data encrypted so that I can utilize IWeb today.

Thanks for getting back to me.
Jun 9, 2008 at 4:55 PM
You are right. I was referring to the DotNetNuke "web context" that is able to determine the portal based on the URL. We could have tried to use that but decided against it. It would cause overhead just to determine the portal number when we can simply require that you pass it. Sessions also create overhead that we did not see as a requirement.
Jun 9, 2008 at 6:41 PM
I totally understand this. It would have been great though to have this as an optional method. It is the only (easy) way to integrate DNN with systems that relay on external authentication from the master-system.

As a workaround I am currently extending my IFrame module which now integrates with IWeb. It can be configured to pass through the necessary data for IWeb auth - so that the client page can successfully call a configured DNN Webservice.

The password is -of course- always encrypted. Either by random UUID or by a Administrator configured key. This is done by the module internatly which is in turn using the IWeb (i.e. Jeff Atwoods) library. It can also be configured for full-parameter pass-through which means that all URL Parameters from the container-page are accessible within the IFrame.

Having a GetLoggedInUser() or GetLoggedInUser(int portalID) method would have enabled a more seamless integration where the consumer doesn´t even need to know about UserID´s and encrypted passwords. Maybe this should be considered for the future.

Jun 9, 2008 at 8:03 PM
Perhaps if you had time to make a proof of concept showing how it would integrate with the existing functionality that would be great. Remember it is an Open Source project so it is open to evolving. Ian is the current project leader and he started out as a contributor.
Jun 11, 2008 at 6:05 AM
Can you give me Headstart on how to recover the current DNN-session from an IWeb enabled WebService? We probably still would need to pass in the portal-ID, right?
I just got into this DNN thing and would need help to do this.
Jun 11, 2008 at 12:08 PM

Elmar wrote:
Can you give me Headstart on how to recover the current DNN-session from an IWeb enabled WebService? We probably still would need to pass in the portal-ID, right?
I just got into this DNN thing and would need help to do this.

I am not sure how to do this. Perhaps the "Users Online" module ( has some helpful code to show who is considered "logged in".
Jun 18, 2008 at 2:47 AM
I have no idea where to start with this either, if you are trying to determine who is logged into the site and automatically pass this to IWeb (am I on the right track here?). But I may have time to tinker with this in the near future. If this is what we are talking about I see this as being a great feature to add in a coming release and would be more than happy to spend some time working on it.

Just to be clear, we are trying to avoid having to pass in the Username and Password to the request and only the PortalId correct?
Jun 18, 2008 at 9:34 AM
- No additional authentication if it has already been done.
- Mimic standard Webservice behaviour (enablesession=true) to distinct between IWeb traditional auth with SOAP Header and automatic authentication pass-through.
- Pass in Portal-ID to seperate multiple active sessions for a user

Actually this feature would enable transparent data exchange with a DNN installation with zero effort from the consumer side.
All sorts of clients (think Silverlight) would be enabled to consume DNN-data without knowledge about the underlying authentication but full Webservice/WCF support.
Now doesn´t that sound sweet?

Let me know if you need input/support/whatever .


Jun 18, 2008 at 12:13 PM
I think we should be careful when adding any complexity to the API. We know that we cannot get the "current logged in user" because there simply is no one logged in through web services. We can simulate the "logged in" behavior but why are we doing this? Will it make the application run any better? The majority of developer's would have a hard time implementing a complex API. Complex headers and keys are not easy to implement from Silverlight and AJAX.
Jun 18, 2008 at 3:06 PM
I hope you don´t get this wrong but I don´t think we are talking about the same thing.
An ASP.NET Webservice can share the session context of an it´s containing ASP.NET Application by design. So if a user is already logged into this ASP.NET Application that information becomes available in the WebService. This is standard design and fully supported by ASP.NET by declaring a method with EnableSession=true.

This -of course- does not work for Users that are not currently authenticated with the ASP.NET Application. So the IWeb authentication mechanism is not obsolete in any way if you need too make a call from an unauthenticated realm. For most of the webservices though the user is logged into the main Application anyway. This is true for the majority of Silverlight- as well as AJAX-apps as well as applications that provide additional functionality to a portal.

All my AJAX-methods access Webservices that operate with an authenticated User´s data without passing any authentication to the service. These services get the User´s information because they use the ability of sharing the Session context. So implementing this with IWeb results in less complex API´s and no keys and a more standard-compliant-behaviour of IWebServices.

Jun 22, 2008 at 11:46 PM

Elmar wrote:
An ASP.NET Webservice can share the session context of an it´s containing ASP.NET Application by design.

With DotNetNuke development we never want to use session variables. For example, I start making web calls and the administrator uploads a module. The web.config is updated and the App Domain is reset... I have lost that session. DotNetNuke avoids everyone suddenly being logged out by not using sessions. It uses Viewstate or profile data that is stored in the database. Also, the DotNetNuke framework does not support this with web farms.

Jun 23, 2008 at 7:32 AM
Ok, that is what I asked about in the first place. In essence I wanted to know if it is possible to support the "EnableSession"-Attribute like in standard ASP.NET Webservices. Thanks a lot for clearing this up, Michael.

For my project I use the standard IWeb C#-project along in conjunction with a seperate, custom DNN-IFrame component that is "IWeb-enabled". It can be configured to pass-trough the User-Data needed to authenticate with an IWeb-Service on the DNN-Portal. That way I essentially get the same behaviour of "automatic" WebSerivce authentication for a user that is already logged into the portal. If anyone is interested I would be willing to contribute the code to the IWeb project.

Jun 23, 2008 at 12:11 PM
I'm sorry I originally misunderstood the question.

My only hesitation with the IFrame implementation is complexity. I am not saying the implementation is bad but that I am concerned when you can't tell a developer simply "call this method and pass the proper values and it will work". Anything else and we lose a bunch of people. If I could remove the "Authentication Header" I would because we lose a lot of people who can't figure that one out. It's not a hard thing to do and it seems like the correect thing to use but when 25% of the developer's get stuck it is something that I wish we left out.
Jun 23, 2008 at 3:15 PM
No need to be sorry. You are the native speaker so it is likely my fault in the first place.

As for the IFrame module - all it does is to include all the data needed by a external application to autenticate successfully with the originating Portal (in which the IFrame component lives). It passes the IWeb authentication bits preencrypted in the URL. This lets developers create solutions that use the IWeb authentication system without needing to know the nitty gritty details because the encrypted authentication bits are already included.

I absolutly understand you concerns. It´s the right thing to do to have simplicity and usability in mind. So just get back to me when feature requests for a solution like this are coming in.

Sep 16, 2008 at 9:41 AM
Hi Elmar, it seems close to what I am looking for.

Logging in from an external IFrame
I have an IFrame residing on an external website pointing to and showing a DNN of mine.
I want the IFrame to send a username/password (or username/token) to the DNN, so that the DNN can log-in with that user,
without showing the Login page.

Before opening the IFrame
Beforehand, when I press on the button that opens the IFrame, the external website calls the DNN to tell it to expect a user, 
via a call to a DNN-IWeb new service which I want to write called ExpectUser( createIfNew:=true ) creating the user if doesn't exist.
This service should be protected and accessible only to a special user which is used from the calling website.

Waiting for the user
Once the ExpectUser() was called, the DNN will log in that username only if called within a short time period,
and only if the correct token (== temporary password) was given.

Does your code answer any of this?

Sep 16, 2008 at 9:56 AM
Hi pashute,

not really. My extension has been developed to automatically authenticate calls from external sources where the DNN portal is the IFrame host.
So in my case I rely on already having a valid user at the DNN portal and make sure that external Iframe content is able to callback successfully to the DNN portal.
It works very well for my business case.