Some Questions Regarding Custom Authentication and WinForms Validation

white_shark posted on Friday, July 20, 2007

Hello,

First of all I am new to the framework, so please excuse if some of the questions are overly simple.

Anyways, here I go.

1) I am trying to implement a custom authentication scheme. As I was trying to follow the approach Rocky used in the book (separate security database) I discovered that my security requirements are different than the ones in the sample application.

The main difference is the fact that there are no publicly browsable areas of the application. In other words, the user has got log in before entering the application.

In Rocky's example there was no validation of data entry and if the user couldn't be authenticated then no porblem just display the app but keep him logged out. In my case I want data to be validated, and to open the application only if the user is succesfully authenticated.

I had a bit of problem with this since the real BO in the example was the PTIdentity object and not the publicly callable PTPrincipal.

I thought about builiding an UserInfo class on top of the clasess in the example that implemented the mentioned feutures but I consider that it is a bit of an overhead. However, I would not like to implement this logic in the UI. Do you think there is a cleaner approach to doing this?

BTW, While I am in the same subject I would like to know what was the of delegating the IsInRole behaviour to the PTIdentiy project, since it was not specifically stated in the book.

2) Windows Forms Validation.

I am trying to implement validation in such a way that the error provider messages do not show up at form load.

I tried using the traditional technique used on "traditional" win forms validation (playing with the CausesValidation and AutoValidate properties) but I have obtained no results.

As I was studying why this happens, tt seems to be that when attaching the object to the appropriate BindingSource, the IDataErrorInterface methods get called several times and that causes the ErrorProvider to display the errors. Btw, Do any of you know why does this get called so often and if this behaviour is random or if there's any way to know when and why this is called?

However I am lost into how to go about implementing a different validation scheme that does not show the errors to the user until he/she submits bad data and if so then highlights the errors through the ErrorProvider Control. What approach do you suggest?

If you got this far thanks for reading, I am sorry. I  know it is a long post and that I should have probably divided it in two.

Thanks for all your help and to Rocky for provding a great book and the framework.

Oswaldo.

PS: Sorry for my English, I am not a native speaker.

JoeFallon1 replied on Friday, July 20, 2007

Hi Oswaldo,

Your English is very good.

Some things to consider:

1. The Identity class does all of the data access to retrieve the data for the user so it makes sense to store the information there. Since the Identity is conatined by the Principal it is simplest to expose IsInRole at the principal level and just forward the call to the Identity object.

2. You should write your own Principal and Identity classes that fetch the information you need for your app.

e.g.

<Serializable()> _
Public Class MyUser
  Inherits Csla.Security.BusinessPrincipalBase

#Region " Constructor "

Private Sub New(ByVal identity As IIdentity)

  MyBase.New(identity)

End Sub

#End Region

etc. (See the book)

==============================================================================

 

<Serializable()> _
Public Class MyBusinessIdentity
  Inherits Csla.ReadOnlyBase(Of MyBusinessIdentity)
  Implements IIdentity

  Private mRoles As New ArrayList
  Private mIsAuthenticated As Boolean = False
  Private mUsername As String = ""

#Region " IIdentity "

Public ReadOnly Property IsAuthenticated() As Boolean Implements IIdentity.IsAuthenticated
  Get
    Return mIsAuthenticated
  End Get
End Property

Public ReadOnly Property AuthenticationType() As String Implements IIdentity.AuthenticationType
  Get
    Return "CSLA"
  End Get
End Property

Public ReadOnly Property Name() As String Implements IIdentity.Name
  Get
    Return mUsername
  End Get
End Property

#End Region

etc.

 

3. As far as validation - I think if you skip the call to ValidationRules.CheckRules() during the Fetch or Create then the BO will not have any broken rules when the screen opens. Most developers make those calls and they usually exist in the CodeSmith templates. But if you don't want them then just comment them out. Be sure you set the fields during Fetch and not the Properties - this also avoids running the rules (one at a time.)

4. Finally, Rocky has said many times that databinding makes multiple calls and the CSLA framework is designed to only honor the first call. See the book.

Joe

white_shark replied on Monday, July 23, 2007

Hi Joe,

Thanks for the tips. I will try your approach towards validation.

Thanks again.

Oswaldo.

PS: Thanks for the comment about my English. It seems that alll those English lessons are paying off. :-D