Interface question

Discussion in 'ASP .Net' started by tshad, Apr 23, 2006.

  1. tshad

    tshad Guest

    I am trying to understand why I would use interfaces.

    In the following example for IPrinciple, I have the following code:

    ************************************************************
    using System;
    using System.Collections;
    using System.Security;
    using System.Security.Principal;

    namespace CustomSecurity
    {
    [Serializable]
    public class CustomPrincipal: IPrincipal
    {
    private IIdentity identity;
    private ArrayList roles;

    public CustomPrincipal(IIdentity id, ArrayList rolesArray)
    {
    identity = id;
    roles = rolesArray;
    }
    public bool IsInRole(string role)
    {
    return roles.Contains( role );
    }

    public IIdentity Identity
    {
    get { return identity; }
    set { identity = value; }
    }
    }
    }
    *****************************************************

    I understand that IPrincipal (and IIdentity) is defined as:

    *********************************************************
    namespace System.Security.Principal {
    interface IIdentity {
    bool IsAuthenticated { get; }
    string AuthenticationType { get; }
    string Name { get; }
    }
    interface IPrincipal {
    IIdentity Identity { get; }
    bool IsInRole(string role);
    }
    }
    **********************************************************

    What would be the difference if I just wrote the code as (I understand that
    I also would have the IIdentity class also).:

    **********************************************************
    using System;
    using System.Collections;
    using System.Security;

    namespace CustomSecurity
    {
    [Serializable]
    public class CustomPrincipal
    {
    private IIdentity identity;
    private ArrayList roles;

    public CustomPrincipal(IIdentity id, ArrayList rolesArray)
    {
    identity = id;
    roles = rolesArray;
    }
    public bool IsInRole(string role)
    {
    return roles.Contains( role );
    }

    public IIdentity Identity
    {
    get { return identity; }
    set { identity = value; }
    }
    }
    }
    *****************************************************

    Does the system handle it any different?

    Thanks,

    Tom
    tshad, Apr 23, 2006
    #1
    1. Advertising

  2. tshad

    David Hogue Guest

    Implementing the IPrinciple interface won't have any affect on how your
    CustomPrincipal class behaves.

    The difference is if you have a function that requires an argument of
    type IPrincipal (sorry I don't have an example handy). You would be
    able to pass an instance of your first CustomPrincipal in to that
    function, but the second would generate a compiler error since it's not
    the right type.

    It's kinda late, so I hope that made sense.

    tshad wrote:
    > I am trying to understand why I would use interfaces.
    >
    > In the following example for IPrinciple, I have the following code:
    >
    > ************************************************************
    > using System;
    > using System.Collections;
    > using System.Security;
    > using System.Security.Principal;
    >
    > namespace CustomSecurity
    > {
    > [Serializable]
    > public class CustomPrincipal: IPrincipal
    > {
    > private IIdentity identity;
    > private ArrayList roles;
    >
    > public CustomPrincipal(IIdentity id, ArrayList rolesArray)
    > {
    > identity = id;
    > roles = rolesArray;
    > }
    > public bool IsInRole(string role)
    > {
    > return roles.Contains( role );
    > }
    >
    > public IIdentity Identity
    > {
    > get { return identity; }
    > set { identity = value; }
    > }
    > }
    > }
    > *****************************************************
    >
    > I understand that IPrincipal (and IIdentity) is defined as:
    >
    > *********************************************************
    > namespace System.Security.Principal {
    > interface IIdentity {
    > bool IsAuthenticated { get; }
    > string AuthenticationType { get; }
    > string Name { get; }
    > }
    > interface IPrincipal {
    > IIdentity Identity { get; }
    > bool IsInRole(string role);
    > }
    > }
    > **********************************************************
    >
    > What would be the difference if I just wrote the code as (I understand that
    > I also would have the IIdentity class also).:
    >
    > **********************************************************
    > using System;
    > using System.Collections;
    > using System.Security;
    >
    > namespace CustomSecurity
    > {
    > [Serializable]
    > public class CustomPrincipal
    > {
    > private IIdentity identity;
    > private ArrayList roles;
    >
    > public CustomPrincipal(IIdentity id, ArrayList rolesArray)
    > {
    > identity = id;
    > roles = rolesArray;
    > }
    > public bool IsInRole(string role)
    > {
    > return roles.Contains( role );
    > }
    >
    > public IIdentity Identity
    > {
    > get { return identity; }
    > set { identity = value; }
    > }
    > }
    > }
    > *****************************************************
    >
    > Does the system handle it any different?
    >
    > Thanks,
    >
    > Tom
    >
    >


    --
    David Hogue
    David Hogue, Apr 23, 2006
    #2
    1. Advertising

  3. tshad

    tshad Guest

    "David Hogue" <> wrote in message
    news:uBH2g.79071$...
    > Implementing the IPrinciple interface won't have any affect on how your
    > CustomPrincipal class behaves.
    >
    > The difference is if you have a function that requires an argument of
    > type IPrincipal (sorry I don't have an example handy). You would be
    > able to pass an instance of your first CustomPrincipal in to that
    > function, but the second would generate a compiler error since it's not
    > the right type.


    Is that the main reason? Other than setting up security, why would I need
    IPrincipal and IIdentity?

    I am not trying to NOT use it. I am just trying to find out why it is
    better than the identical code, without the IPrincipal inheritance.

    I assume that the windows Authorization, such as Forms, doesn't need it. I
    mean does windows (IIS) look for IPrincipal and IIdentity when it is using
    managed security context?

    Also, is CustomPrincipal of type IPrincipal just because it inherits from it
    (maybe I am getting inheritance confused with interfaces).

    I am trying to see all the reasons why to use interfaces.

    Thanks,

    Tom

    >
    > It's kinda late, so I hope that made sense.
    >
    > tshad wrote:
    > > I am trying to understand why I would use interfaces.
    > >
    > > In the following example for IPrinciple, I have the following code:
    > >
    > > ************************************************************
    > > using System;
    > > using System.Collections;
    > > using System.Security;
    > > using System.Security.Principal;
    > >
    > > namespace CustomSecurity
    > > {
    > > [Serializable]
    > > public class CustomPrincipal: IPrincipal
    > > {
    > > private IIdentity identity;
    > > private ArrayList roles;
    > >
    > > public CustomPrincipal(IIdentity id, ArrayList rolesArray)
    > > {
    > > identity = id;
    > > roles = rolesArray;
    > > }
    > > public bool IsInRole(string role)
    > > {
    > > return roles.Contains( role );
    > > }
    > >
    > > public IIdentity Identity
    > > {
    > > get { return identity; }
    > > set { identity = value; }
    > > }
    > > }
    > > }
    > > *****************************************************
    > >
    > > I understand that IPrincipal (and IIdentity) is defined as:
    > >
    > > *********************************************************
    > > namespace System.Security.Principal {
    > > interface IIdentity {
    > > bool IsAuthenticated { get; }
    > > string AuthenticationType { get; }
    > > string Name { get; }
    > > }
    > > interface IPrincipal {
    > > IIdentity Identity { get; }
    > > bool IsInRole(string role);
    > > }
    > > }
    > > **********************************************************
    > >
    > > What would be the difference if I just wrote the code as (I understand

    that
    > > I also would have the IIdentity class also).:
    > >
    > > **********************************************************
    > > using System;
    > > using System.Collections;
    > > using System.Security;
    > >
    > > namespace CustomSecurity
    > > {
    > > [Serializable]
    > > public class CustomPrincipal
    > > {
    > > private IIdentity identity;
    > > private ArrayList roles;
    > >
    > > public CustomPrincipal(IIdentity id, ArrayList rolesArray)
    > > {
    > > identity = id;
    > > roles = rolesArray;
    > > }
    > > public bool IsInRole(string role)
    > > {
    > > return roles.Contains( role );
    > > }
    > >
    > > public IIdentity Identity
    > > {
    > > get { return identity; }
    > > set { identity = value; }
    > > }
    > > }
    > > }
    > > *****************************************************
    > >
    > > Does the system handle it any different?
    > >
    > > Thanks,
    > >
    > > Tom
    > >
    > >

    >
    > --
    > David Hogue
    tshad, Apr 23, 2006
    #3
  4. tshad

    David Hogue Guest

    tshad wrote:
    > "David Hogue" <> wrote in message
    > news:uBH2g.79071$...
    >> Implementing the IPrinciple interface won't have any affect on how your
    >> CustomPrincipal class behaves.
    >>
    >> The difference is if you have a function that requires an argument of
    >> type IPrincipal (sorry I don't have an example handy). You would be
    >> able to pass an instance of your first CustomPrincipal in to that
    >> function, but the second would generate a compiler error since it's not
    >> the right type.

    >
    > Is that the main reason? Other than setting up security, why would I need
    > IPrincipal and IIdentity?


    My understanding of IPrincipal and IIdentity isn't the best, but I
    believe they are used primarily for security. Setting user roles and
    that kind of thing.

    > I am not trying to NOT use it. I am just trying to find out why it is
    > better than the identical code, without the IPrincipal inheritance.


    It's only better if you need treat the class as an IPrincipal.

    > I assume that the windows Authorization, such as Forms, doesn't need it. I
    > mean does windows (IIS) look for IPrincipal and IIdentity when it is using
    > managed security context?


    Windows and Forms based authentication both use the interfaces, but you
    don't need to interact with them directly unless you want to change
    default behavior.

    For example: The company I work for has a system with users and roles
    stored in a database. When a request is authenticated we get a list of
    roles and create a GenericPrincipal (GenericPrincipal implements
    IPrincipal):

    string[] userRoles = db.GetUserRoles(Context.User.Identity.Name);
    Context.User = new GenericPrincipal(Context.User.Identity, userRoles);

    Though we didn't use a custom principal class we could have and it might
    look something like this:

    public class SmartzPrincipal : IPrincipal
    {
    private IIdentity identity;
    public SmartzPrincipal(IIdentity identity)
    {
    this.identity = identity;
    }

    public IIdentity Identity
    {
    get { return identity; }
    }

    public IsInRoles(String role)
    {
    List<string> roles = db.GetUserRoles(identity.Name);
    return roles.Contains(role);
    }
    }

    Then we would use it like so:

    Context.User = new SmartzPrincipal(Context.User.Identity);

    While the version with the interface looks longer in my example it would
    actually be simpler than what we have. It would encapsulate all the
    role based code in one place and be more reusable.

    > Also, is CustomPrincipal of type IPrincipal just because it inherits from it
    > (maybe I am getting inheritance confused with interfaces).


    Implements is the word I hear most often when referring to interfaces.
    It's really the same concept as inheriting from a base class, except you
    can implement multiple interfaces and only inherit from one base class.

    CustomPrincipal is of type IPrincipal because it implements it.

    > I am trying to see all the reasons why to use interfaces.
    >
    > Thanks,
    >
    > Tom


    I hope I'm helping and not just confusing things...

    --
    David Hogue
    David Hogue, Apr 23, 2006
    #4
  5. tshad

    tshad Guest

    "David Hogue" <> wrote in message
    news:NoS2g.168323$...
    > tshad wrote:
    >> "David Hogue" <> wrote in message
    >> news:uBH2g.79071$...
    >>> Implementing the IPrinciple interface won't have any affect on how your
    >>> CustomPrincipal class behaves.
    >>>
    >>> The difference is if you have a function that requires an argument of
    >>> type IPrincipal (sorry I don't have an example handy). You would be
    >>> able to pass an instance of your first CustomPrincipal in to that
    >>> function, but the second would generate a compiler error since it's not
    >>> the right type.

    >>
    >> Is that the main reason? Other than setting up security, why would I
    >> need
    >> IPrincipal and IIdentity?

    >
    > My understanding of IPrincipal and IIdentity isn't the best, but I
    > believe they are used primarily for security. Setting user roles and
    > that kind of thing.
    >
    >> I am not trying to NOT use it. I am just trying to find out why it is
    >> better than the identical code, without the IPrincipal inheritance.

    >
    > It's only better if you need treat the class as an IPrincipal.
    >
    >> I assume that the windows Authorization, such as Forms, doesn't need it.
    >> I
    >> mean does windows (IIS) look for IPrincipal and IIdentity when it is
    >> using
    >> managed security context?

    >
    > Windows and Forms based authentication both use the interfaces, but you
    > don't need to interact with them directly unless you want to change
    > default behavior.
    >
    > For example: The company I work for has a system with users and roles
    > stored in a database. When a request is authenticated we get a list of
    > roles and create a GenericPrincipal (GenericPrincipal implements
    > IPrincipal):


    That is what I am curious about.

    When you talk about users and roles stored in a database, are you talking
    about Windows Users and Roles (User Policies)?

    I assume you can't use the GenericPrincipal to handle your own users and
    roles, such as office managers and their roles. These would be stored in
    your own database and the GenericPrincipal wouldn't know about that.

    >
    > string[] userRoles = db.GetUserRoles(Context.User.Identity.Name);
    > Context.User = new GenericPrincipal(Context.User.Identity, userRoles);
    >
    > Though we didn't use a custom principal class we could have and it might
    > look something like this:
    >


    If you didn't use a custom principal class, I assume you don't store your
    own users, roles a policies, right?

    > public class SmartzPrincipal : IPrincipal
    > {
    > private IIdentity identity;
    > public SmartzPrincipal(IIdentity identity)
    > {
    > this.identity = identity;
    > }
    >
    > public IIdentity Identity
    > {
    > get { return identity; }
    > }
    >
    > public IsInRoles(String role)
    > {
    > List<string> roles = db.GetUserRoles(identity.Name);
    > return roles.Contains(role);
    > }
    > }
    >
    > Then we would use it like so:
    >
    > Context.User = new SmartzPrincipal(Context.User.Identity);
    >
    > While the version with the interface looks longer in my example it would
    > actually be simpler than what we have. It would encapsulate all the
    > role based code in one place and be more reusable.
    >
    >> Also, is CustomPrincipal of type IPrincipal just because it inherits from
    >> it
    >> (maybe I am getting inheritance confused with interfaces).

    >
    > Implements is the word I hear most often when referring to interfaces.
    > It's really the same concept as inheriting from a base class, except you
    > can implement multiple interfaces and only inherit from one base class.
    >
    > CustomPrincipal is of type IPrincipal because it implements it.
    >
    >> I am trying to see all the reasons why to use interfaces.
    >>
    >> Thanks,
    >>
    >> Tom

    >
    > I hope I'm helping and not just confusing things...


    You are. I am just trying to really understand it. I sort of understand
    interfaces, but am trying to find the reasons to use them vs when not to use
    them. Just because you can doesn't mean you should (in all cases).

    Thanks,

    Tom
    >
    > --
    > David Hogue
    tshad, Apr 25, 2006
    #5
  6. tshad

    David Hogue Guest

    tshad wrote:
    > "David Hogue" <> wrote in message
    > news:NoS2g.168323$...
    >> tshad wrote:
    >>> "David Hogue" <> wrote in message
    >>> news:uBH2g.79071$...
    >>>> Implementing the IPrinciple interface won't have any affect on how your
    >>>> CustomPrincipal class behaves.
    >>>>
    >>>> The difference is if you have a function that requires an argument of
    >>>> type IPrincipal (sorry I don't have an example handy). You would be
    >>>> able to pass an instance of your first CustomPrincipal in to that
    >>>> function, but the second would generate a compiler error since it's not
    >>>> the right type.
    >>> Is that the main reason? Other than setting up security, why would I
    >>> need
    >>> IPrincipal and IIdentity?

    >> My understanding of IPrincipal and IIdentity isn't the best, but I
    >> believe they are used primarily for security. Setting user roles and
    >> that kind of thing.
    >>
    >>> I am not trying to NOT use it. I am just trying to find out why it is
    >>> better than the identical code, without the IPrincipal inheritance.

    >> It's only better if you need treat the class as an IPrincipal.
    >>
    >>> I assume that the windows Authorization, such as Forms, doesn't need it.
    >>> I
    >>> mean does windows (IIS) look for IPrincipal and IIdentity when it is
    >>> using
    >>> managed security context?

    >> Windows and Forms based authentication both use the interfaces, but you
    >> don't need to interact with them directly unless you want to change
    >> default behavior.
    >>
    >> For example: The company I work for has a system with users and roles
    >> stored in a database. When a request is authenticated we get a list of
    >> roles and create a GenericPrincipal (GenericPrincipal implements
    >> IPrincipal):

    >
    > That is what I am curious about.
    >
    > When you talk about users and roles stored in a database, are you talking
    > about Windows Users and Roles (User Policies)?
    >
    > I assume you can't use the GenericPrincipal to handle your own users and
    > roles, such as office managers and their roles. These would be stored in
    > your own database and the GenericPrincipal wouldn't know about that.
    >

    We can (and did) use GenericPrincipal to handle our own users and roles.
    This is because it is a "generic", for lack of a better term,
    implementation of the IPrincipal interface. We can give a
    GenericPrincipal an array of strings and it will return true from the
    IsInRoles method if that role is in the array.

    We did't have to create our own class that implemented IPrincipal,
    GenericPrincipal was already there for us. However the downside is that
    the code to get the users from the database still has to go somewhere
    and it ended up mixed in with a bunch of unrelated code.

    >> string[] userRoles = db.GetUserRoles(Context.User.Identity.Name);
    >> Context.User = new GenericPrincipal(Context.User.Identity, userRoles);
    >>
    >> Though we didn't use a custom principal class we could have and it might
    >> look something like this:
    >>

    >
    > If you didn't use a custom principal class, I assume you don't store your
    > own users, roles a policies, right?
    >
    >> public class SmartzPrincipal : IPrincipal
    >> {
    >> private IIdentity identity;
    >> public SmartzPrincipal(IIdentity identity)
    >> {
    >> this.identity = identity;
    >> }
    >>
    >> public IIdentity Identity
    >> {
    >> get { return identity; }
    >> }
    >>
    >> public IsInRoles(String role)
    >> {
    >> List<string> roles = db.GetUserRoles(identity.Name);
    >> return roles.Contains(role);
    >> }
    >> }
    >>
    >> Then we would use it like so:
    >>
    >> Context.User = new SmartzPrincipal(Context.User.Identity);
    >>
    >> While the version with the interface looks longer in my example it would
    >> actually be simpler than what we have. It would encapsulate all the
    >> role based code in one place and be more reusable.
    >>
    >>> Also, is CustomPrincipal of type IPrincipal just because it inherits from
    >>> it
    >>> (maybe I am getting inheritance confused with interfaces).

    >> Implements is the word I hear most often when referring to interfaces.
    >> It's really the same concept as inheriting from a base class, except you
    >> can implement multiple interfaces and only inherit from one base class.
    >>
    >> CustomPrincipal is of type IPrincipal because it implements it.
    >>
    >>> I am trying to see all the reasons why to use interfaces.
    >>>
    >>> Thanks,
    >>>
    >>> Tom

    >> I hope I'm helping and not just confusing things...

    >
    > You are. I am just trying to really understand it. I sort of understand
    > interfaces, but am trying to find the reasons to use them vs when not to use
    > them. Just because you can doesn't mean you should (in all cases).
    >

    Interfaces and some of the more abstract object oriented ideas can be
    difficult to fully understand. I've been working with object oriented
    languages for years, but it's only relatively recently that my code has
    become more object oriented.

    I would suggest reading up on design patterns for some insight into how
    interfaces are often used. There was a recent article on codebetter.com
    that might be a good place to start:
    http://codebetter.com/blogs/jeremy.miller/archive/2006/04/11/142665.aspx

    --
    David Hogue
    David Hogue, Apr 25, 2006
    #6
  7. David very good links there
    Patrick
    "David Hogue" <> wrote in message
    news:z3g3g.101597$...
    > tshad wrote:
    >> "David Hogue" <> wrote in message
    >> news:NoS2g.168323$...
    >>> tshad wrote:
    >>>> "David Hogue" <> wrote in message
    >>>> news:uBH2g.79071$...
    >>>>> Implementing the IPrinciple interface won't have any affect on how
    >>>>> your
    >>>>> CustomPrincipal class behaves.
    >>>>>
    >>>>> The difference is if you have a function that requires an argument of
    >>>>> type IPrincipal (sorry I don't have an example handy). You would be
    >>>>> able to pass an instance of your first CustomPrincipal in to that
    >>>>> function, but the second would generate a compiler error since it's
    >>>>> not
    >>>>> the right type.
    >>>> Is that the main reason? Other than setting up security, why would I
    >>>> need
    >>>> IPrincipal and IIdentity?
    >>> My understanding of IPrincipal and IIdentity isn't the best, but I
    >>> believe they are used primarily for security. Setting user roles and
    >>> that kind of thing.
    >>>
    >>>> I am not trying to NOT use it. I am just trying to find out why it is
    >>>> better than the identical code, without the IPrincipal inheritance.
    >>> It's only better if you need treat the class as an IPrincipal.
    >>>
    >>>> I assume that the windows Authorization, such as Forms, doesn't need
    >>>> it.
    >>>> I
    >>>> mean does windows (IIS) look for IPrincipal and IIdentity when it is
    >>>> using
    >>>> managed security context?
    >>> Windows and Forms based authentication both use the interfaces, but you
    >>> don't need to interact with them directly unless you want to change
    >>> default behavior.
    >>>
    >>> For example: The company I work for has a system with users and roles
    >>> stored in a database. When a request is authenticated we get a list of
    >>> roles and create a GenericPrincipal (GenericPrincipal implements
    >>> IPrincipal):

    >>
    >> That is what I am curious about.
    >>
    >> When you talk about users and roles stored in a database, are you talking
    >> about Windows Users and Roles (User Policies)?
    >>
    >> I assume you can't use the GenericPrincipal to handle your own users and
    >> roles, such as office managers and their roles. These would be stored in
    >> your own database and the GenericPrincipal wouldn't know about that.
    >>

    > We can (and did) use GenericPrincipal to handle our own users and roles.
    > This is because it is a "generic", for lack of a better term,
    > implementation of the IPrincipal interface. We can give a
    > GenericPrincipal an array of strings and it will return true from the
    > IsInRoles method if that role is in the array.
    >
    > We did't have to create our own class that implemented IPrincipal,
    > GenericPrincipal was already there for us. However the downside is that
    > the code to get the users from the database still has to go somewhere
    > and it ended up mixed in with a bunch of unrelated code.
    >
    >>> string[] userRoles = db.GetUserRoles(Context.User.Identity.Name);
    >>> Context.User = new GenericPrincipal(Context.User.Identity, userRoles);
    >>>
    >>> Though we didn't use a custom principal class we could have and it might
    >>> look something like this:
    >>>

    >>
    >> If you didn't use a custom principal class, I assume you don't store your
    >> own users, roles a policies, right?
    >>
    >>> public class SmartzPrincipal : IPrincipal
    >>> {
    >>> private IIdentity identity;
    >>> public SmartzPrincipal(IIdentity identity)
    >>> {
    >>> this.identity = identity;
    >>> }
    >>>
    >>> public IIdentity Identity
    >>> {
    >>> get { return identity; }
    >>> }
    >>>
    >>> public IsInRoles(String role)
    >>> {
    >>> List<string> roles = db.GetUserRoles(identity.Name);
    >>> return roles.Contains(role);
    >>> }
    >>> }
    >>>
    >>> Then we would use it like so:
    >>>
    >>> Context.User = new SmartzPrincipal(Context.User.Identity);
    >>>
    >>> While the version with the interface looks longer in my example it would
    >>> actually be simpler than what we have. It would encapsulate all the
    >>> role based code in one place and be more reusable.
    >>>
    >>>> Also, is CustomPrincipal of type IPrincipal just because it inherits
    >>>> from
    >>>> it
    >>>> (maybe I am getting inheritance confused with interfaces).
    >>> Implements is the word I hear most often when referring to interfaces.
    >>> It's really the same concept as inheriting from a base class, except you
    >>> can implement multiple interfaces and only inherit from one base class.
    >>>
    >>> CustomPrincipal is of type IPrincipal because it implements it.
    >>>
    >>>> I am trying to see all the reasons why to use interfaces.
    >>>>
    >>>> Thanks,
    >>>>
    >>>> Tom
    >>> I hope I'm helping and not just confusing things...

    >>
    >> You are. I am just trying to really understand it. I sort of understand
    >> interfaces, but am trying to find the reasons to use them vs when not to
    >> use
    >> them. Just because you can doesn't mean you should (in all cases).
    >>

    > Interfaces and some of the more abstract object oriented ideas can be
    > difficult to fully understand. I've been working with object oriented
    > languages for years, but it's only relatively recently that my code has
    > become more object oriented.
    >
    > I would suggest reading up on design patterns for some insight into how
    > interfaces are often used. There was a recent article on codebetter.com
    > that might be a good place to start:
    > http://codebetter.com/blogs/jeremy.miller/archive/2006/04/11/142665.aspx
    >
    > --
    > David Hogue
    Patrick.O.Ige, Apr 25, 2006
    #7
  8. tshad

    tshad Guest

    "David Hogue" <> wrote in message
    news:z3g3g.101597$...
    > tshad wrote:
    >> "David Hogue" <> wrote in message
    >> news:NoS2g.168323$...
    >>> tshad wrote:
    >>>> "David Hogue" <> wrote in message
    >>>> news:uBH2g.79071$...
    >>>>> Implementing the IPrinciple interface won't have any affect on how
    >>>>> your
    >>>>> CustomPrincipal class behaves.
    >>>>>
    >>>>> The difference is if you have a function that requires an argument of
    >>>>> type IPrincipal (sorry I don't have an example handy). You would be
    >>>>> able to pass an instance of your first CustomPrincipal in to that
    >>>>> function, but the second would generate a compiler error since it's
    >>>>> not
    >>>>> the right type.
    >>>> Is that the main reason? Other than setting up security, why would I
    >>>> need
    >>>> IPrincipal and IIdentity?
    >>> My understanding of IPrincipal and IIdentity isn't the best, but I
    >>> believe they are used primarily for security. Setting user roles and
    >>> that kind of thing.
    >>>
    >>>> I am not trying to NOT use it. I am just trying to find out why it is
    >>>> better than the identical code, without the IPrincipal inheritance.
    >>> It's only better if you need treat the class as an IPrincipal.
    >>>
    >>>> I assume that the windows Authorization, such as Forms, doesn't need
    >>>> it.
    >>>> I
    >>>> mean does windows (IIS) look for IPrincipal and IIdentity when it is
    >>>> using
    >>>> managed security context?
    >>> Windows and Forms based authentication both use the interfaces, but you
    >>> don't need to interact with them directly unless you want to change
    >>> default behavior.
    >>>
    >>> For example: The company I work for has a system with users and roles
    >>> stored in a database. When a request is authenticated we get a list of
    >>> roles and create a GenericPrincipal (GenericPrincipal implements
    >>> IPrincipal):

    >>
    >> That is what I am curious about.
    >>
    >> When you talk about users and roles stored in a database, are you talking
    >> about Windows Users and Roles (User Policies)?
    >>
    >> I assume you can't use the GenericPrincipal to handle your own users and
    >> roles, such as office managers and their roles. These would be stored in
    >> your own database and the GenericPrincipal wouldn't know about that.
    >>

    > We can (and did) use GenericPrincipal to handle our own users and roles.
    > This is because it is a "generic", for lack of a better term,
    > implementation of the IPrincipal interface. We can give a
    > GenericPrincipal an array of strings and it will return true from the
    > IsInRoles method if that role is in the array.
    >
    > We did't have to create our own class that implemented IPrincipal,
    > GenericPrincipal was already there for us. However the downside is that
    > the code to get the users from the database still has to go somewhere
    > and it ended up mixed in with a bunch of unrelated code.
    >
    >>> string[] userRoles = db.GetUserRoles(Context.User.Identity.Name);
    >>> Context.User = new GenericPrincipal(Context.User.Identity, userRoles);


    I assume that if you use the GenericPrincipal, you need to use it as is and
    if you want to add anything else (another method, some special test, read
    from your user table etc) , you would need to create another class (as you
    did below with SmartzPrincipal).

    >>>
    >>> Though we didn't use a custom principal class we could have and it might
    >>> look something like this:
    >>>


    This is my question.

    If you created your SmartzPrincipal and you used all the methods defined in
    IPrincipal, why use IPrincipal at all?

    What does it do for you? That's what I am trying to get my mind around.

    >>
    >> If you didn't use a custom principal class, I assume you don't store your
    >> own users, roles a policies, right?
    >>
    >>> public class SmartzPrincipal : IPrincipal
    >>> {
    >>> private IIdentity identity;
    >>> public SmartzPrincipal(IIdentity identity)
    >>> {
    >>> this.identity = identity;
    >>> }
    >>>
    >>> public IIdentity Identity
    >>> {
    >>> get { return identity; }
    >>> }
    >>>
    >>> public IsInRoles(String role)
    >>> {
    >>> List<string> roles = db.GetUserRoles(identity.Name);
    >>> return roles.Contains(role);
    >>> }
    >>> }
    >>>
    >>> Then we would use it like so:
    >>>
    >>> Context.User = new SmartzPrincipal(Context.User.Identity);
    >>>
    >>> While the version with the interface looks longer in my example it would
    >>> actually be simpler than what we have. It would encapsulate all the
    >>> role based code in one place and be more reusable.
    >>>
    >>>> Also, is CustomPrincipal of type IPrincipal just because it inherits
    >>>> from
    >>>> it
    >>>> (maybe I am getting inheritance confused with interfaces).
    >>> Implements is the word I hear most often when referring to interfaces.
    >>> It's really the same concept as inheriting from a base class, except you
    >>> can implement multiple interfaces and only inherit from one base class.
    >>>
    >>> CustomPrincipal is of type IPrincipal because it implements it.
    >>>
    >>>> I am trying to see all the reasons why to use interfaces.
    >>>>
    >>>> Thanks,
    >>>>
    >>>> Tom
    >>> I hope I'm helping and not just confusing things...

    >>
    >> You are. I am just trying to really understand it. I sort of understand
    >> interfaces, but am trying to find the reasons to use them vs when not to
    >> use
    >> them. Just because you can doesn't mean you should (in all cases).
    >>

    > Interfaces and some of the more abstract object oriented ideas can be
    > difficult to fully understand. I've been working with object oriented
    > languages for years, but it's only relatively recently that my code has
    > become more object oriented.
    >
    > I would suggest reading up on design patterns for some insight into how
    > interfaces are often used. There was a recent article on codebetter.com
    > that might be a good place to start:
    > http://codebetter.com/blogs/jeremy.miller/archive/2006/04/11/142665.aspx


    Looks like a great article.

    Will look at it later today.

    Thanks,

    Tom
    >
    > --
    > David Hogue
    tshad, Apr 25, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Wildepiet
    Replies:
    0
    Views:
    1,860
    Wildepiet
    Jun 14, 2004
  2. cyberco
    Replies:
    8
    Views:
    487
    cyberco
    Feb 25, 2006
  3. Xah Lee
    Replies:
    15
    Views:
    584
    Sherm Pendley
    Mar 23, 2007
  4. Xah Lee
    Replies:
    15
    Views:
    630
    Sherm Pendley
    Mar 23, 2007
  5. Replies:
    4
    Views:
    345
    timjowers
    Nov 2, 2007
Loading...

Share This Page