Mar13Written by:Will
3/13/2009
For the longest time, DotNetNuke has assumed in many areas that administrators and hosts know what they're doing. Why shouldn't we assume that? I will not advocate that we should rethink that philosophy, because I don't believe that should. But the DNN team has done just that with a usability "feature" that was introduced in DotNetNuke version 5.00.00.
A well-known feature of DNN, is allowing administrators to change the "page" that is used when a visitor clicks the Login link on a DNN site. This is very useful if you want to decorate the login form with advertising, instructions, or if you want to enable SSL on the login page. It's easy enough to do as well. Just login using an account with administrator permissions. Then change the setting, like shown in the screen shot below.
Once you choose the page, and click the Update link at the bottom of the Site Settings, you will now be able to login on the selected page, right? Not always. The first step that countless people have overlooked in this process, is adding the Account Login module to the selected page, BEFORE logging off of the website. Missing this step has essentially made your DNN site inaccessible to everyone using every known trick.
Basically, when a visitor would click the login link following the login page update, the page would reload, sans a login form. Fortunately, this was easily fixed using the following query:
1:-- replacing XXX with the correct portal id, normally 0
2:UPDATE [dbo].[Portals] SET [LoginTabId] = NULLWHERE [PortalID] = XXX
Admittedly, I cannot tell you how many times this single query has earned me a little bit of consulting income. The DNN core team has put an end to that.
Starting with DotNetNuke version 5.00.00, when DNN sees that the Account Login module is not on the page, it will do it for you. This little usability update will save countless numbers of people an untold amount of frustration.
Why Do I Hate this Feature?
My title playfully said that I hate this update, but that's not true. I am surprised that this update hasn't made it into the code base sooner. And I am no longer going to be able to charge for this service. *sniffles*
How Did I Find this Update?
I was presenting a session to the Space Coast SQL Server User Group in Melbourne, Florida last night. One of my demos consisted of re-enabling the login as described above. Being a good DNN evangelist (self-titled), I was using the most current version of DNN (5.00.01). Boy was I embarrassed at this. But it got some good laughs. I think a lot of people secretly hope for demos to fail anyway. :)
11 comment(s) so far...
Awesome Will, I had no clue this was fixed in DNN5.
By Tom Kraak on
3/13/2009 |
Seems something of a double edged sword - what if i write my own login module? how does it detect the login module? I will have to investigate this more!
By Dylan Barber on
3/13/2009 |
May we continue to disappoint you in this way... *grin*
By Scott on
3/13/2009 |
@tkraak @scott In all seriousness, this is a great feature to have. This would tick off a bunch of newbies. And really, it was no fault of their own. In the very least, they should have been warned about the implications, but this is a much better and less intrusive "fix".
@Dylan That is a very good question. We would have to try it. But I am certain that the DNN one would be put in place of your intended login module. That being said, your use case is a much more advanced use case. Chances are great that if you know how and why to change out a login module, you're aware of this login page "bug".
Thanks for the comments!
By Will on
3/13/2009 |
@Dylan: Funny you bring that up. I just went through that fun yesterday trying to use a custom login control I wrote that could be skinned per portal. As a hack (in lieu of modifying the core) I ended up having to add the Account Login control to the page with my custom login control, then make the Account Login control invisible to all users.
But even that wasn't the end of it. The LOGIN skin object automatically appends ctl/Login to the link to the login page, so I had to write a substitute skin object to use in place of this as well.
By Tim Goodin on
3/24/2009 |
and by the way, I consider this a bug :)
By Tim Goodin on
3/24/2009 |
@Dylan @Will. If you created your own logon module the proper way (ie. created your own authentication provider), than you are ok...
By erikvb on
3/24/2009 |
@erikvb - You're right, but that doesn't apply to the overwhelming majority of the current DNN site hosts/admins. And especially not in the case of newbies who may be evaluating DNN to see if it matches their business needs.
By Will on
3/24/2009 |
It's a question that I am asking myself so I am raising the issue in the DNN private forum.
By Néstor Sánchez on
3/24/2009 |
@Will - I don't understand your objection to Erik's point. A login control written to the authentication provider would behave correctly. Anything else is an unsupported use case. Calling the fact that we don't support 3rd party login systems that aren't built as auth providers a bug in DNN is like saying that it is a bug that the Toyota Prius doesn't support the use of Monster Truck tires. The prius was not designed for Monster Truck tires and DNN was not built to support alternative login systems (other than the defined auth provider).
By Joe Brinkman on
3/24/2009 |
@jbrinkman I am just saying that a newbie would probably not even know of that option. Especially someone as new as a management type that might be evaluating DNN. We know and take for granted that such extensibility exists, and even more so that the extensibility in some areas solves or creates problems. That's all. I am not disputing the point, just a slice of the populous that that the point doesn't apply to easily.
By Will on
3/24/2009 |