self-inflicted authentication issue

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • kpg

    #1

    self-inflicted authentication issue

    ASP.NET 2.0

    I have an unusual situation dealing with forms authentication,
    not doubt brought on by how I have structured the application.

    The setup:

    Users enter the site from one of several pages, A,B,C, etc.
    These pages allow all users. In theses pages I setup site
    customizing session variables then redirect users to a common
    home page.

    The home page is protected by deny anonymous users, so users
    are sent to a login page to be authenticated. Authentication
    is based on how they entered the site, A,B,C.

    I set things up this way so I can use a common login page,
    but that page is customized based on how the user entered the
    site: A,B,C. (different logo, text, etc.).

    The problem:

    Let's say a user entered on page 'A', gets authenticated and
    is sitting on the home page. Then they edit the browser URL
    to navigate to page 'B'. (the user should not do this, but
    users do all sorts of thing they shouldn't do).

    Well, since the user is already authenticated the login screen
    is by-passed. Additionally, since the home page is already
    loaded in their browser, the home Page_Load event is not fired.
    This results in Page A authentication but Page B session
    variables - a big mess

    To solve this problem I want to un-authenticate the user in
    the page_load event of the entry pages (A,B,C..), but removing
    the ASPXAUTH cookie does not seems to unauthenticate the user
    as the login page is not displayed for some reason, but it does
    force the home page_load event, so this is half correct - but
    still no good.

    I tried setting the web.config to allow anonymous, deny all on
    the entry pages (A,B,C), and this works upon normal entry, but
    when the user navigates there after authorization they can't
    get past the login screen, because once they are authorized
    they are denied access to the requested entry page and sent
    back to the login page - and endless loop.

    I did come up with something that works: I check for the
    ..ASPXAUTH cookie on the entry page and if it is present I
    send the user to an error page.

    To improve on this I keep a session variable "LastValidPage" ,
    and if the user enters the site while authenticated (the
    cookie is present) I simply redirect them to this page, so
    from the users standpoint nothing has happened.

    My question is - is there a better way?

    I thought of having each entry page actually be a customized
    login page (but I like the idea of having a single login page).

    I'm not sure how this would work, the home page would deny
    anonymous, so the system would want to redirect to a
    login.aspx page - I suppose I could have the login.aspx page
    display an error message instead of presenting a login. If
    the user tried to access the home page directly they would
    get the login error page. Then if the user changed to a
    different entry page mid-site, they would need to login based
    on that page's criteria and everything could be kept straight.


    Thoughts or comments?

    Thanks.
    kpg




  • Mr. Arnold

    #2
    Re: self-inflicted authentication issue


    "kpg" <no@spam.comwro te in message
    news:Xns99765FF 101465ipostther eforeiam@207.46 .248.16...
    ASP.NET 2.0
    >
    I have an unusual situation dealing with forms authentication,
    not doubt brought on by how I have structured the application.
    >
    The setup:
    >
    Users enter the site from one of several pages, A,B,C, etc.
    These pages allow all users. In theses pages I setup site
    customizing session variables then redirect users to a common
    home page.
    >
    The home page is protected by deny anonymous users, so users
    are sent to a login page to be authenticated. Authentication
    is based on how they entered the site, A,B,C.
    >
    I set things up this way so I can use a common login page,
    but that page is customized based on how the user entered the
    site: A,B,C. (different logo, text, etc.).
    >
    The problem:
    >
    Let's say a user entered on page 'A', gets authenticated and
    is sitting on the home page. Then they edit the browser URL
    to navigate to page 'B'. (the user should not do this, but
    users do all sorts of thing they shouldn't do).
    >
    Well, since the user is already authenticated the login screen
    is by-passed. Additionally, since the home page is already
    loaded in their browser, the home Page_Load event is not fired.
    This results in Page A authentication but Page B session
    variables - a big mess
    PGBET APK 2.5.0 hadir dengan slot Android terlengkap: unduh gratis 47 MB, panel RTP real-time, QRIS kilat, ratusan game provider resmi.

    >
    Thoughts or comments?
    >
    Why don't you pass an encrypted key between the Web pages? If the URL has
    the encrypted key, then you proceed because your program supplied the
    correct key in the URL, otherwise, you stop them or redirect them to a *I
    got to slap you in the face for this* page.

    Comment

    • kpg

      #3
      Re: self-inflicted authentication issue

      "Mr. Arnold" <MR. Arnold@Arnold.c omwrote in
      news:u6rulDVzHH A.4824@TK2MSFTN GP02.phx.gbl:
      Why don't you pass an encrypted key between the Web pages? If the URL
      has the encrypted key, then you proceed because your program supplied
      the correct key in the URL, otherwise, you stop them or redirect them
      to a *I got to slap you in the face for this* page.
      So you suggest I handle the authentication myself? I like the way you
      think. I was 'trying' to do things the 'right way', by that I mean
      using the login control and web.config settings, but like in so many
      other areas I find that doing it myself is better.

      So without the sekrit key I deny access and redirect to an error page,
      other than that, all pages are allow anonymous.

      I tried my multi-login page technique (which the sekrit key technique
      will also use) but with forms authentication even if I authenticate the
      user I get sent to the login.aspx page <sigh>. I'm sure there's some
      config file I can edit to change that, but I still have the issue that
      I will have multiple login pages (as I have found this works out better
      for several other unrelated reasons).

      So yes, I like your idea - thanks.

      kpg

      Comment

      • Mr. Arnold

        #4
        Re: self-inflicted authentication issue


        "kpg" <no@spam.comwro te in message
        news:Xns99769D9 37356ipostthere foreiam@207.46. 248.16...
        "Mr. Arnold" <MR. Arnold@Arnold.c omwrote in
        news:u6rulDVzHH A.4824@TK2MSFTN GP02.phx.gbl:
        >
        >Why don't you pass an encrypted key between the Web pages? If the URL
        >has the encrypted key, then you proceed because your program supplied
        >the correct key in the URL, otherwise, you stop them or redirect them
        >to a *I got to slap you in the face for this* page.
        >
        So you suggest I handle the authentication myself? I like the way you
        think. I was 'trying' to do things the 'right way', by that I mean
        using the login control and web.config settings, but like in so many
        other areas I find that doing it myself is better.
        >
        So without the sekrit key I deny access and redirect to an error page,
        other than that, all pages are allow anonymous.
        If the solution is to be used by the public or not, it's a means of stopping
        them from going where they want, by entering the URL and going there. You
        should still keep secuirty in mind, and if a login provides that, then you
        should implement that as well.
        >
        I tried my multi-login page technique (which the sekrit key technique
        will also use) but with forms authentication even if I authenticate the
        user I get sent to the login.aspx page <sigh>. I'm sure there's some
        config file I can edit to change that, but I still have the issue that
        I will have multiple login pages (as I have found this works out better
        for several other unrelated reasons).
        >
        So yes, I like your idea - thanks.
        >
        I got that from MCTS 70-528 where they were talking about Encrypting the
        QueryString.

        Sometimes, one has to think out side the box. And nothing is the wrong way
        if it works for you.

        Comment

        Working...