Loading ...
Sorry, an error occurred while loading the content.
 

Re: Trick PerlAuthzHandler into thinking Basic Auth occurred

Expand Messages
  • Geoffrey Young
    ... ah :) then all you should need to do is set $r- user to the authenticated user and you should be good to go. for completeness, you might also want to set
    Message 1 of 18 , Aug 30, 2004
      > Heh. Yeah, maybe the point I needed to make more clear is this. The
      > PerlAuthenHandler is NOT relying on basic auth to actually have ever
      > occured. It is a handler that gets credentials via another service
      > altogether. Suffice it to say that no basic auth ever happens, but my
      > PerlAuthenHandler gets a username. Now, I want to fool the authz
      > module, which expects basic auth to have occurred, into thinking that
      > basic auth occurred. So, somehow I need to setup the
      > environment/request object/etc. to accomplish this.

      ah :)

      then all you should need to do is set $r->user to the authenticated user and
      you should be good to go. for completeness, you might also want to set
      $r->connection->auth_type to 'Basic', but that is most likely not required
      to get things working.

      for more discussions on hacking together your own authentication mechanism,
      where both of these things are discussed, see recipes 13.7 and 13.8 in the
      mod_perl developer's cookbook. all of chapter 13 can be read online for free:

      http://www.modperlcookbook.org/chapters/ch13.pdf

      HTH

      --Geoff

      --
      Report problems: http://perl.apache.org/bugs/
      Mail list info: http://perl.apache.org/maillist/modperl.html
      List etiquette: http://perl.apache.org/maillist/email-etiquette.html
    • David Castro
      ... Hrmm. Yeah, this is what I had thought and tried at one point with no luck. When I use basic auth and let mod_authz_ldap do it s thing, I get ...basic
      Message 2 of 18 , Aug 30, 2004
        on 08/30/04 12:09 Geoffrey Young wrote:
        Heh.  Yeah, maybe the point I needed to make more clear is this.  The
        PerlAuthenHandler is NOT relying on basic auth to actually have ever
        occured.  It is a handler that gets credentials via another service
        altogether.  Suffice it to say that no basic auth ever happens, but my
        PerlAuthenHandler gets a username.  Now, I want to fool the authz
        module, which expects basic auth to have occurred, into thinking that
        basic auth occurred.  So, somehow I need to setup the
        environment/request object/etc. to accomplish this.
            
        ah :)
        
        then all you should need to do is set $r->user to the authenticated user and
        you should be good to go.  for completeness, you might also want to set
        $r->connection->auth_type to 'Basic', but that is most likely not required
        to get things working.
          
        Hrmm.  Yeah, this is what I had thought and tried at one point with no luck.  When I use basic auth and let mod_authz_ldap do it's thing, I get "...basic LDAP authentication of user 'test'...", but with my auth module (using the code above) I get "...on user '(null)' failed..." in my logs.  So, basic auth is doing something that I am not to get that user set for the underlying authz module, I just can't figure out what the heck it is.
        for more discussions on hacking together your own authentication mechanism,
        where both of these things are discussed, see recipes 13.7 and 13.8 in the
        mod_perl developer's cookbook.  all of chapter 13 can be read online for free:
        
          http://www.modperlcookbook.org/chapters/ch13.pdf
        
        HTH
        
        --Geoff
        
          


        -- 
        David Castro
        Software Architect
        Azusa Pacific University
        
        "My little children, let us not love in word or in tongue,
        but in deed and in truth." -- 1 Jn 3:18 (NKJ) 
        
      • Geoffrey Young
        ... well, I can t find either of those error messages in mod_auth_ldap from http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html on in
        Message 3 of 18 , Aug 30, 2004
          >> then all you should need to do is set $r->user to the authenticated
          >> user and
          >> you should be good to go. for completeness, you might also want to set
          >> $r->connection->auth_type to 'Basic', but that is most likely not
          >> required
          >> to get things working.
          >>
          >>
          > Hrmm. Yeah, this is what I had thought and tried at one point with no
          > luck. When I use basic auth and let mod_authz_ldap do it's thing, I get
          > "...basic LDAP authentication of user 'test'...", but with my auth
          > module (using the code above) I get "...on user '(null)' failed..." in
          > my logs. So, basic auth is doing something that I am not to get that
          > user set for the underlying authz module, I just can't figure out what
          > the heck it is.

          well, I can't find either of those error messages in mod_auth_ldap from

          http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html

          on in httpd-2.0, so I'm not sure exactly where the error is coming from.
          one thing of interest is that in the former code they call
          ap_get_basic_auth_pw() from the authz phase, which is clearly wrong and will
          subvert the approach I outlined above. but if you can't set the
          Authorization header either (recipe 13.4) and have it work then I don't know.

          anyway, if you give me a pointer to the mod_auth_ldap code you're using I
          can look it over and see, but there are only a few different places where
          the user information can come from - $r->user directly, or from the
          Authorization header.

          well, I guess there is a third - mod_auth_ldap could assume (or require)
          that it is the authentication handler and instead of looking in those two
          places it could rely on some internal cache. in fact, this seems to be the
          case, as the "AuthLDAPAuthoritative" directive seems to be designed exactly
          for this purpose. the docs indicate that you should set it to "no" if you
          want to use something other than mod_auth_ldap for the authentication phase,
          which is what you are trying to do. so, have you set this directive and
          tried a the other two approaches (setting the incoming header and/or just
          $r->user)?

          --Geoff

          --
          Report problems: http://perl.apache.org/bugs/
          Mail list info: http://perl.apache.org/maillist/modperl.html
          List etiquette: http://perl.apache.org/maillist/email-etiquette.html
        • David Castro
          ... Ooops, yeah. A follow-up email corrected mod_authz_ldap to mod_auth_ldap . Sorry bout that. To give a bit more detail, I am using
          Message 4 of 18 , Aug 30, 2004
            on 08/30/04 13:43 Geoffrey Young wrote:
            then all you should need to do is set $r->user to the authenticated
            user and
            you should be good to go.  for completeness, you might also want to set
            $r->connection->auth_type to 'Basic', but that is most likely not
            required
            to get things working.
             
            
                  
            Hrmm.  Yeah, this is what I had thought and tried at one point with no
            luck.  When I use basic auth and let mod_authz_ldap do it's thing, I get
            "...basic LDAP authentication of user 'test'...", but with my auth
            module (using the code above) I get "...on user '(null)' failed..." in
            my logs.  So, basic auth is doing something that I am not to get that
            user set for the underlying authz module, I just can't figure out what
            the heck it is.
                
            well, I can't find either of those error messages in mod_auth_ldap from
            
              http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html
            
              
            Ooops, yeah.  A follow-up email corrected "mod_authz_ldap" to "mod_auth_ldap".  Sorry 'bout that.  To give a bit more detail, I am using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0.  Went looking through the C code of the authz module and found the function it gets the credentials from:

            char    *authz_ldap_get_userdn(request_rec *r) {
                authz_ldap_config_rec   *sec;
                sec = ap_get_module_config(r->per_dir_config, &authz_ldap_module);
                return sec->userdn;
            }

            Here is the debugging lines for mod_authz_ldap from my apache logs:

            [Mon Aug 30 14:21:07 2004] [debug] authz.c(412): [client 10.10.105.236] [11032]
            authz_ldap_authz called by user '(null)' for URI '/test/'
            [Mon Aug 30 14:21:07 2004] [debug] utilities.c(38): [client 10.10.105.236] [11032] initialize LDAP connection
            [Mon Aug 30 14:21:07 2004] [debug] utilities.c(60): [client 10.10.105.236] [11032] got ldap connection to *************:389 at 0x08dc05d8
            [Mon Aug 30 14:21:07 2004] [debug] utilities.c(74): [client 10.10.105.236] [11032] protocol version set to 3
            [Mon Aug 30 14:21:07 2004] [debug] utilities.c(135): [client 10.10.105.236] [11032] bind to ldap server succeeded
            [Mon Aug 30 14:21:07 2004] [debug] authz.c(423): [client 10.10.105.236] [11032]
            LDAP connection established
            [Mon Aug 30 14:21:07 2004] [debug] authz.c(446): [client 10.10.105.236] [11032]
            starting with return code 0
            [Mon Aug 30 14:21:07 2004] [debug] authz.c(460): [client 10.10.105.236] [11032]
            processing requirement role 507
            [Mon Aug 30 14:21:07 2004] [debug] authz.c(513): [client 10.10.105.236] [11032]
            role(s) required: 507
            [Mon Aug 30 14:21:07 2004] [debug] authz.c(199): [client 10.10.105.236] [11032]
            allocating 20 bytes for role filter
            [Mon Aug 30 14:21:07 2004] [debug] authz.c(204): [client 10.10.105.236] [11032]
            role filter: (gidNumber=507)
            [Mon Aug 30 14:21:07 2004] [debug] filterexpand.c(50): [client 10.10.105.236] performing substitutions in filter '(gidNumber=507)'
            [Mon Aug 30 14:21:07 2004] [debug] filterexpand.c(102): [client 10.10.105.236] filter substitutions give new filter '(gidNumber=507)'
            [Mon Aug 30 14:21:07 2004] [debug] authz.c(47): [client 10.10.105.236] [11032] checking filter '(null)' for user '(gidNumber=507)'
            [Mon Aug 30 14:21:07 2004] [debug] utilities.c(174): [client 10.10.105.236] [11032] search from '(null)' for '(gidNumber=507)' returns 32
            [Mon Aug 30 14:21:07 2004] [debug] utilities.c(191): [client 10.10.105.236] [11032] retry the search
            [Mon Aug 30 14:21:07 2004] [error] [client 10.10.105.236] ldap [11032] search for filter '(gidNumber=507)', scope = 0 on user '(null)' failed
            [Mon Aug 30 14:21:07 2004] [debug] authz.c(209): [client 10.10.105.236] [11032]
            role requirement failed
            [Mon Aug 30 14:21:07 2004] [debug] authz.c(585): [client 10.10.105.236] authz_ldap_authz()[11032]: elapsed time: 37ms, cpu time: 0ms
            [Mon Aug 30 14:21:07 2004] [debug] authz.c(587): [client 10.10.105.236] [11032]
            return code from authz_ldap_authz: NOK (403)

            on in httpd-2.0, so I'm not sure exactly where the error is coming from.
            one thing of interest is that in the former code they call
            ap_get_basic_auth_pw() from the authz phase, which is clearly wrong and will
            subvert the approach I outlined above.  but if you can't set the
            Authorization header either (recipe 13.4) and have it work then I don't know.
            
            anyway, if you give me a pointer to the mod_auth_ldap code you're using I
            can look it over and see, but there are only a few different places where
            the user information can come from - $r->user directly, or from the
            Authorization header.
            
            well, I guess there is a third - mod_auth_ldap could assume (or require)
            that it is the authentication handler and instead of looking in those two
            places it could rely on some internal cache.  in fact, this seems to be the
            case, as the "AuthLDAPAuthoritative" directive seems to be designed exactly
            for this purpose.  the docs indicate that you should set it to "no" if you
            want to use something other than mod_auth_ldap for the authentication phase,
            which is what you are trying to do.  so, have you set this directive and
            tried a the other two approaches (setting the incoming header and/or just
            $r->user)?
            
            --Geoff
            
              


            -- 
            David Castro
            Software Architect
            Azusa Pacific University
            
            "My little children, let us not love in word or in tongue,
            but in deed and in truth." -- 1 Jn 3:18 (NKJ) 
            
          • Geoffrey Young
            ... well, close - I think it s authz_ldap_set_username but the problem is the same... basically, mod_authz_ldap is caching the given username in it s private
            Message 5 of 18 , Aug 30, 2004
              > Ooops, yeah. A follow-up email corrected "mod_authz_ldap" to
              > "mod_auth_ldap". Sorry 'bout that. To give a bit more detail, I am
              > using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0. Went looking
              > through the C code of the authz module and found the function it gets
              > the credentials from:
              >
              > char *authz_ldap_get_userdn(request_rec *r) {
              > authz_ldap_config_rec *sec;
              > sec = ap_get_module_config(r->per_dir_config, &authz_ldap_module);
              > return sec->userdn;
              > }

              well, close - I think it's authz_ldap_set_username but the problem is the
              same...

              basically, mod_authz_ldap is caching the given username in it's private
              stash - r->per_dir_config is generally used to refer to the httpd.conf
              configuration data that applies to the current request. so, what I think is
              going on here is one of the scenarios I posited before:
              authz_ldap_set_username is only called in auth.c, so if you don't use
              mod_authz_ldap to do your authentication then you are SOL, since it uses
              it's cached version of the username instead of grabbing it from one of the
              standard places after authentication.

              my suggestion would be to play around with the mod_auth_ldap that ships with
              httpd-2.0 - it is likely to be moved from experimental in the next release
              IIRC and is much more well-behaved (judging from both the authors and
              conversations I've been following).

              another approach is to try to play around with this module's private data.
              you can use this code as an example
              http://www.modperlcookbook.org/code/ch08/Cookbook-LanguagePriority-0.01.tar.gz

              but I'm afraid the corresponding explanations are not online. and I haven't
              (yet) proven that this approach works with 2.0, so YMMV.

              HTH

              --Geoff

              --
              Report problems: http://perl.apache.org/bugs/
              Mail list info: http://perl.apache.org/maillist/modperl.html
              List etiquette: http://perl.apache.org/maillist/email-etiquette.html
            • David Castro
              ... Yeah, I just found that in authz_ldap_set_username too. Sigh. Well, thanks for your help. ... -- David Castro Software Architect Azusa Pacific University
              Message 6 of 18 , Aug 30, 2004
                on 08/30/04 15:01 Geoffrey Young wrote:
                Ooops, yeah.  A follow-up email corrected "mod_authz_ldap" to
                "mod_auth_ldap".  Sorry 'bout that.  To give a bit more detail, I am
                using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0.  Went looking
                through the C code of the authz module and found the function it gets
                the credentials from:
                
                char    *authz_ldap_get_userdn(request_rec *r) {
                   authz_ldap_config_rec   *sec;
                   sec = ap_get_module_config(r->per_dir_config, &authz_ldap_module);
                   return sec->userdn;
                }
                    
                well, close - I think it's authz_ldap_set_username but the problem is the
                same...
                
                basically, mod_authz_ldap is caching the given username in it's private
                stash - r->per_dir_config is generally used to refer to the httpd.conf
                configuration data that applies to the current request.  so, what I think is
                going on here is one of the scenarios I posited before:
                authz_ldap_set_username is only called in auth.c, so if you don't use
                mod_authz_ldap to do your authentication then you are SOL, since it uses
                it's cached version of the username instead of grabbing it from one of the
                standard places after authentication.
                
                my suggestion would be to play around with the mod_auth_ldap that ships with
                httpd-2.0 - it is likely to be moved from experimental in the next release
                IIRC and is much more well-behaved (judging from both the authors and
                conversations I've been following).
                
                another approach is to try to play around with this module's private data.
                you can use this code as an example
                  http://www.modperlcookbook.org/code/ch08/Cookbook-LanguagePriority-0.01.tar.gz
                
                but I'm afraid the corresponding explanations are not online.  and I haven't
                (yet) proven that this approach works with 2.0, so YMMV.
                  
                Yeah, I just found that in authz_ldap_set_username too.  Sigh. 

                Well, thanks for your help.
                HTH
                
                --Geoff
                
                  


                -- 
                David Castro
                Software Architect
                Azusa Pacific University
                
                "My little children, let us not love in word or in tongue,
                but in deed and in truth." -- 1 Jn 3:18 (NKJ) 
                
              • David Castro
                Okay, a little more tracking down revealed that handler #5 ( check if the user is ok _here_ ) is never getting called when my module is being used, but is for
                Message 7 of 18 , Aug 30, 2004
                  Okay, a little more tracking down revealed that handler #5 ("check if the user is ok _here_") is never getting called when my module is being used, but is for Basic auth.  Happen to know under which circumstances this occurs/doesn't occur?  Maybe there is something else I can set to get that mechanism called in the first place.  This appears to be the main problem I have right now, preventing me from moving forward.


                  on 08/30/04 15:12 David Castro wrote:
                  on 08/30/04 15:01 Geoffrey Young wrote:
                  Ooops, yeah.  A follow-up email corrected "mod_authz_ldap" to
                  "mod_auth_ldap".  Sorry 'bout that.  To give a bit more detail, I am
                  using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0.  Went looking
                  through the C code of the authz module and found the function it gets
                  the credentials from:
                  
                  char    *authz_ldap_get_userdn(request_rec *r) {
                     authz_ldap_config_rec   *sec;
                     sec = ap_get_module_config(r->per_dir_config, &authz_ldap_module);
                     return sec->userdn;
                  }
                      
                  well, close - I think it's authz_ldap_set_username but the problem is the
                  same...
                  
                  basically, mod_authz_ldap is caching the given username in it's private
                  stash - r->per_dir_config is generally used to refer to the httpd.conf
                  configuration data that applies to the current request.  so, what I think is
                  going on here is one of the scenarios I posited before:
                  authz_ldap_set_username is only called in auth.c, so if you don't use
                  mod_authz_ldap to do your authentication then you are SOL, since it uses
                  it's cached version of the username instead of grabbing it from one of the
                  standard places after authentication.
                  
                  my suggestion would be to play around with the mod_auth_ldap that ships with
                  httpd-2.0 - it is likely to be moved from experimental in the next release
                  IIRC and is much more well-behaved (judging from both the authors and
                  conversations I've been following).
                  
                  another approach is to try to play around with this module's private data.
                  you can use this code as an example
                    http://www.modperlcookbook.org/code/ch08/Cookbook-LanguagePriority-0.01.tar.gz
                  
                  but I'm afraid the corresponding explanations are not online.  and I haven't
                  (yet) proven that this approach works with 2.0, so YMMV.
                    
                  Yeah, I just found that in authz_ldap_set_username too.  Sigh. 

                  Well, thanks for your help.
                  HTH
                  
                  --Geoff
                  
                    


                  -- 
                  David Castro
                  Software Architect
                  Azusa Pacific University
                  
                  "My little children, let us not love in word or in tongue,
                  but in deed and in truth." -- 1 Jn 3:18 (NKJ) 
                    


                  -- 
                  David Castro
                  Software Architect
                  Azusa Pacific University
                  
                  "My little children, let us not love in word or in tongue,
                  but in deed and in truth." -- 1 Jn 3:18 (NKJ) 
                  
                • Geoffrey Young
                  ... I don t see anything funny in the code to short-circuit the request cycle, so I would assume that things progress as they ordinarily would, which is like
                  Message 8 of 18 , Aug 30, 2004
                    David Castro wrote:
                    > Okay, a little more tracking down revealed that handler #5 ("check if
                    > the user is ok _here_") is never getting called when my module is being
                    > used, but is for Basic auth. Happen to know under which circumstances
                    > this occurs/doesn't occur? Maybe there is something else I can set to
                    > get that mechanism called in the first place. This appears to be the
                    > main problem I have right now, preventing me from moving forward.

                    I don't see anything funny in the code to short-circuit the request cycle,
                    so I would assume that things progress as they ordinarily would, which is
                    like this:

                    o apache checks for a "Requires" directive, signaling that the authen and
                    authz phases should be run.

                    o the authentication phase runs:

                    - apache calls mod_perl, which dispatches to your PerlAuthenHandler.

                    - your PerlAuthenHandler returns OK and ends the authen phase. or your
                    handler returns 403 (or some other error) and immediately goes to the
                    logging phase.

                    o the authorization phase runs

                    - apache calls mod_perl, which dispatches to your PerlAuthzHandler (if
                    any). if that handler returns OK then thus ends the authz phase, and
                    mod_authz_ldap will _not_run. if there are no PerlAuthzHandlers registered
                    then apache will dispatch to mod_authz_ldap.

                    basically, these parts are somewhat separated from eachother - apache will
                    call whatever handlers are registered (your #5 above) and those handlers
                    will run unless the handlers themselves take special steps to avoid being
                    run (and return DECLINED so other authentication can occur). I don't see
                    any signs of that, so I don't know what to say. that is, other than check
                    out the mod_auth_ldap that ships with httpd-2.0 and see if it is any better
                    behaved than this module.

                    HTH

                    --Geoff

                    --
                    Report problems: http://perl.apache.org/bugs/
                    Mail list info: http://perl.apache.org/maillist/modperl.html
                    List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                  • Thomas Lochmatter
                    You re right: both methods (content_languages() and content_language()) work on the Apache object, although only content_languages() is documented (perldoc
                    Message 9 of 18 , Sep 1, 2004
                      You're right: both methods (content_languages() and
                      content_language()) work on the Apache object, although
                      only content_languages() is documented (perldoc Apache)!

                      Since Apache::FakeRequest wants to be a complete fake
                      object, it should implement both methods as well, I think.
                      Hence, the patch would be to add content_languages()
                      instead of replacing content_language().

                      -- Thomas

                      Um Fri, 27 Aug 2004 19:25:41 -0700
                      schrieb Stas Bekman <stas@...>:
                      > Thomas Lochmatter wrote:
                      > > (ModPerl 1.29, Apache.pm 1.27, FakeRequest.pm 1.00)
                      > >
                      > > In the Apache::FakeRequest module, there is a method
                      > called
                      > > "content_language". The Apache module however calls
                      > this
                      > > method "content_languages".
                      > >
                      > > I guess this is a bug. It could be corrected by
                      > changing
                      > > FakeRequest.pm, line 20:
                      > > < content content_encoding content_language
                      > >
                      > >> content content_encoding content_languages
                      >
                      > Why do you think it's a bug? there are both
                      > content_language and content_languages in
                      > src/modules/perl/Apache.xs:
                      >
                      > char *
                      > content_language(r, ...)
                      > Apache r
                      >
                      > CODE:
                      > get_set_PVp(r->content_language,r->pool);
                      >
                      > OUTPUT:
                      > RETVAL
                      >
                      > void
                      > content_languages(r, avrv=Nullsv)
                      > Apache r
                      > SV *avrv
                      >
                      > PREINIT:
                      > I32 gimme = GIMME_V;
                      >
                      > CODE:
                      > if(avrv && SvROK(avrv))
                      > r->content_languages = avrv2array_header(avrv,
                      > r->pool);
                      >
                      > if(gimme != G_VOID)
                      > ST(0) = array_header2avrv(r->content_languages);
                      >
                      > --
                      >
                      __________________________________________________________________
                      > Stas Bekman JAm_pH ------> Just Another
                      > mod_perl Hacker
                      > http://stason.org/ mod_perl Guide --->
                      > http://perl.apache.org
                      > mailto:stas@... http://use.perl.org
                      > http://apacheweek.com
                      > http://modperlbook.org http://apache.org
                      > http://ticketmaster.com


                      --
                      Report problems: http://perl.apache.org/bugs/
                      Mail list info: http://perl.apache.org/maillist/modperl.html
                      List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                    • Geoffrey Young
                      ... FakeRequest is really kinda painful. is there any reason why you aren t using Apache-Test to create a live testing environment instead?
                      Message 10 of 18 , Sep 1, 2004
                        Thomas Lochmatter wrote:
                        > You're right: both methods (content_languages() and
                        > content_language()) work on the Apache object, although
                        > only content_languages() is documented (perldoc Apache)!
                        >
                        > Since Apache::FakeRequest wants to be a complete fake
                        > object, it should implement both methods as well, I think.
                        > Hence, the patch would be to add content_languages()
                        > instead of replacing content_language().

                        FakeRequest is really kinda painful. is there any reason why you aren't
                        using Apache-Test to create a live testing environment instead?

                        http://search.cpan.org/dist/Apache-Test/

                        --Geoff

                        --
                        Report problems: http://perl.apache.org/bugs/
                        Mail list info: http://perl.apache.org/maillist/modperl.html
                        List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                      • Thomas Lochmatter
                        Thanks for the hint. I didn t know about Apache::Test. It seems to be a quite big testing framework. I use Apache::FakeRequest for debugging (while developing)
                        Message 11 of 18 , Sep 2, 2004
                          Thanks for the hint. I didn't know about Apache::Test. It
                          seems to be a quite big testing framework.

                          I use Apache::FakeRequest for debugging (while developing)
                          rather than for testing. The advantage is that it's very
                          simple/small/handy and does exactly what I need: a fake
                          Apache object replacement.

                          -- Thomas

                          Um Wed, 01 Sep 2004 13:45:27 -0400
                          schrieb Geoffrey Young <geoff@...>:
                          >
                          >
                          > Thomas Lochmatter wrote:
                          > > You're right: both methods (content_languages() and
                          > > content_language()) work on the Apache object, although
                          > > only content_languages() is documented (perldoc
                          > Apache)!
                          > >
                          > > Since Apache::FakeRequest wants to be a complete fake
                          > > object, it should implement both methods as well, I
                          > think.
                          > > Hence, the patch would be to add content_languages()
                          > > instead of replacing content_language().
                          >
                          > FakeRequest is really kinda painful. is there any reason
                          > why you aren't
                          > using Apache-Test to create a live testing environment
                          > instead?
                          >
                          > http://search.cpan.org/dist/Apache-Test/
                          >
                          > --Geoff
                          >
                          > --
                          > Report problems: http://perl.apache.org/bugs/
                          > Mail list info:
                          > http://perl.apache.org/maillist/modperl.html
                          > List etiquette:
                          > http://perl.apache.org/maillist/email-etiquette.html
                          >


                          --
                          Report problems: http://perl.apache.org/bugs/
                          Mail list info: http://perl.apache.org/maillist/modperl.html
                          List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                        • Geoffrey Young
                          ... it can be big or small, depending on what you need it to be :) ... you could do both - test-driven development. personally, I don t know how I ever got
                          Message 12 of 18 , Sep 2, 2004
                            Thomas Lochmatter wrote:
                            > Thanks for the hint. I didn't know about Apache::Test. It
                            > seems to be a quite big testing framework.

                            it can be big or small, depending on what you need it to be :)

                            > I use Apache::FakeRequest for debugging (while developing)
                            > rather than for testing.

                            you could do both - test-driven development. personally, I don't know how I
                            ever got along without Apache-Test, for both development and debugging. how
                            I wrote applications before seemed insane when compared to using the tools
                            we now have available.

                            > The advantage is that it's very
                            > simple/small/handy and does exactly what I need: a fake
                            > Apache object replacement.

                            sometimes what we think we need it's what we really need ;)

                            I'd encourage you (and everyone) to give Apache-Test a try. to kickstart
                            the adventure, after installing Apache-Test from CPAN you can try plugging
                            in your module to this skeleton

                            http://perl.apache.org/~geoff/Apache-Test-skeleton-mp1.tar.gz

                            basically, typing 'make test' will start the server in a pristine
                            environment and run through your test scripts. and even if you don't (yet)
                            have test script, you can just 't/TEST -start-httpd' to start apache and
                            keep it running while you hit against it with a browser. yeah, that's
                            pretty much the same as hitting your ordinary dev box, except that you can
                            isolate the config much easier with Apache-Test, making it possible to add
                            self-contained tests later.

                            anyway, HTH

                            --Geoff

                            --
                            Report problems: http://perl.apache.org/bugs/
                            Mail list info: http://perl.apache.org/maillist/modperl.html
                            List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                          • William McKee
                            ... +1. A::T has helped me to write my code, to catch errors that I ve introduced while adding new features, and to do code refactoring (which I ve done quite
                            Message 13 of 18 , Sep 2, 2004
                              On Thu, Sep 02, 2004 at 08:03:01AM -0400, Geoffrey Young wrote:
                              > you could do both - test-driven development. personally, I don't know how I
                              > ever got along without Apache-Test, for both development and debugging. how
                              > I wrote applications before seemed insane when compared to using the tools
                              > we now have available.

                              +1.

                              A::T has helped me to write my code, to catch errors that I've introduced
                              while adding new features, and to do code refactoring (which I've done
                              quite a bit of as I learn to use Class::DBI). It took me awhile to get
                              the gist of it (as you can read if you look back in the docs-dev mailling
                              list) but it was worth the effort. Start with Geoff's article and
                              skeleton; you'll avoid many of the potholes I hit along the way.


                              William

                              --
                              Knowmad Services Inc.
                              http://www.knowmad.com

                              --
                              Report problems: http://perl.apache.org/bugs/
                              Mail list info: http://perl.apache.org/maillist/modperl.html
                              List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                            Your message has been successfully submitted and would be delivered to recipients shortly.