Manager.Login always returns true - why must we throw LoginException?

Hi, Adam:

You are correct that a call to EntityManager.Login() will always return true unless an exception is encountered. Thus we expect you to call that method from your client code within a Try-Catch block. But even if you fail to do so, no unauthorized user will ever get access to your data through the EntityServer, which I think you would probably agree would be even worse than an application crash.

Suppose, on the other hand, that we were simply to return true or false from the call to EntityManager.Login(), and depend upon you to test the value and respond accordingly. In that case if you happened to forget to test the result – these things happen!  -- then we would have that worst-case scenario of unauthorized access to the data.

Since so much is at stake, we prefer to err on the side of greater security.

You could return a null IPrincipal from your IEntityLoginManager.Login() implementation, but as you have observed you would not be able to use the return value of EntityManager.Login() to assess the success of the authentication request.  Instead you would need to test the IPrincipal attached by DevForce to the client-side thread; or more, specifically, that IPrincipal’s Identity:

            System.Threading.Thread.CurrentPrincipal.Identity.IsAuthenticated

IsAuthenticated would have a value of false in the case where your IEntityLoginManager.Login() implementation returns a null.  (The System.Threading.Thread.CurrentPrincipal that gets set after you return a null IPrincipal from IEntityLoginManager.Login() is not itself null, so you could not test that for nullness.)

Note that returning a null IPrincipal from your IEntityLoginManager.Login() method will also result in an invalid IdeaBlade.EntityModel.SessionBundle. The SessionBundle created by the call to EntityManager.Login() is used to authenticate each subsequent communication between the EntityManager and EntityServer. Thus, the first attempt to access the latter (as by issuing a query) would result in an exception. You would have to be sure not to attempt to access the EntityServer after a failed login.

I personally think it much more advisable to stay with the intended paradigm, call EntityManager.Login() within a try-catch, and treat any sort of exception resulting from the call as a reason not to permit access to your data.   FYI, we have included a code sample that implements authentication and role-based authorization security in our most recent release of DevForce. Due to recent changes in many assembly names in DevForce you will need that release to run it; but you could of course simply inspect it without running it.



Edited by GregD - 13-May-2009 at 4:03pm

I've come accross another problem now: how do I specify more than the built in types of LoginExceptionType? I need to add two more reasons for login failure that are not supported by IdeaBlade's LoginExceptionTypes... I tried throwing my own home grown exception type, but my type is converted to a generic "IdeaBlade.EntityModel.EntityServerException" so that I cannot catch it specifically, nor does the "IdeaBlade.EntityModel.EntityServerException" store my custom exception in it's InnerException property. What am I to do? I cannot place the failure reason in the returned IPrincipal because there is no returned IPrincipal when authentication fails... (the reasons I need to support are "temporary password expired" and "account is locked")... Any advice would be appreciated!

Hi,

Hi,