SitePoint Sponsor

User Tag List

Results 1 to 4 of 4
  1. #1
    SitePoint Enthusiast siteartwork's Avatar
    Join Date
    Jan 2005
    Location
    Germany
    Posts
    67
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Front Controller & User Authentication

    Hey@all,

    I have a design issue that I wan't to share with you in hope to get some good ideas.

    I'm currently implementing a Front Controller and I'm unsure where's the best place to put user authentication: Should it be global, defined in the FilterChain of a Intercepting Filter or should it be placed in the Model layer, so I can return a "failure" to the command as has access to the view and react appropriately to it?

    IMHO, if I use a Intercepting Filter, I'm pretty much bound to a header-redirect, and AFAICS this prevends the system to provide some extended information why the requested operation has failed...

    What's your experience with this?

  2. #2
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There are two things here: user authentication (eg. check session) and user authorization (ie. check if the user has the rights to perform the action). In most cases you're likely to have authentication at the global level and task-based authorization at the local. The reasons are as above.

  3. #3
    SitePoint Enthusiast siteartwork's Avatar
    Join Date
    Jan 2005
    Location
    Germany
    Posts
    67
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi Ezku, thank you for your reply. I studied the filter concept as descriped in J2EE Patterns and I would agree with you by now.

    However, my assumption that I'd have to re-dispatch the request using a header-redirect to a "authentication-not-valid" page without having further information about the failure was wrong, since a Filter has acces to the passed in request-object (this would be in our case the $_REQUEST-global) and can manipulate it, i.e. change the command/action-param _before_ the processRequest() of the Front Controller gets called. In this way, the filter can change the requested command to the appropriate command as it wants.

  4. #4
    SitePoint Member
    Join Date
    Sep 2005
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    IMHO, if I use a Intercepting Filter, I'm pretty much bound to a header-redirect, and AFAICS this prevends the system to provide some extended information why the requested operation has failed...
    Not necessarily - assuming your filter has a problem, it can simply pull a solution like:

    PHP Code:
    <?php

    class Filter_Authentication extends InterceptingFilter {

        var 
    $nextFilter;

        function 
    Filter_Authentication(&$nextFilter) {
            
    $this->nextFilter $nextFilter
        
    }

        function 
    processRequest() {
            if(
    $_SESSION['authenticated'] != 'true'
            {
                
    //something wrong
                
    $class $this->getBadAuthCommand();
                if(require_once(
    'path/to/' $class '.php')) {
                {
                    
    $command = new $class();
                    
    $command->execute();
                    
    $command->render();
                }
            }
            
    $this->nextFilter->processRequest();
        }

        function 
    getBadAuthCommand() {
            return 
    'BadAuthCommand';
        }

    }

    ?>
    Just execute a relevant Command object that won't require a redirect...


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •