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

Re: [soaplite] Accessing HTTP Auth from a SOAP service

Expand Messages
  • Byrne Reese
    You can t do that in 0.60. Try 0.65. But you could use mod_auth_mysql or my_auth_postgres which are Apache plugins which will automatically do
    Message 1 of 8 , May 2, 2005
    View Source
    • 0 Attachment
      You can't do that in 0.60. Try 0.65.

      But you could use mod_auth_mysql or my_auth_postgres which are Apache
      plugins which will automatically do username/passsword lookups for you
      from a set of Basic Auth credentials.

      http://www.majordojo.com/archives/000636.php

      Paul TBBle Hampson wrote:

      > I'm creating a SOAP service which I want to
      > username/password protect, against the database
      > the service modifies.
      >
      > It seems to me that the easiest way to do this
      > would be to have access to the username/password
      > sent in by the client via HTTP basic auth
      > available somehow to the eventual perl functions.
      >
      > However, I can't see any way to do this.
      >
      > Have I missed something important, or am I trying
      > to do something impossible?
      >
      > I'm on the Debian 0.60 package at the moment,
      > and using the mod_soap (Apache::SOAP mod_perl
      > handler) method to run, although I can change
      > that if needed. (I'd _rather_ run it through
      > Apache2 since I get access it's HTTPS setup
      > for free that way. ^_^)
      >
      >
      >
      >
      > ------------------------------------------------------------------------
      > *Yahoo! Groups Links*
      >
      > * To visit your group on the web, go to:
      > http://groups.yahoo.com/group/soaplite/
      >
      > * To unsubscribe from this group, send an email to:
      > soaplite-unsubscribe@yahoogroups.com
      > <mailto:soaplite-unsubscribe@yahoogroups.com?subject=Unsubscribe>
      >
      > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
      > Service <http://docs.yahoo.com/info/terms/>.
      >
      >
    • paul.hampson@pobox.com
      ... That wouldn t help, as I need to know which record it was that the username/password identified. ... This covers the client, but I need to do it in the
      Message 2 of 8 , May 2, 2005
      View Source
      • 0 Attachment
        On Mon, May 02, 2005 at 07:36:03AM -0700, Byrne Reese wrote:
        > You can't do that in 0.60. Try 0.65.

        > But you could use mod_auth_mysql or my_auth_postgres which are Apache
        > plugins which will automatically do username/passsword lookups for you
        > from a set of Basic Auth credentials.

        That wouldn't help, as I need to know which record it was that the
        username/password identified.

        > http://www.majordojo.com/archives/000636.php

        This covers the client, but I need to do it in the server-side
        functions, where I don't actually have any SOAP objects.

        I can get the SOM by putting something in @ISA, but I can't see
        how I can use that to get to the HTTP::Request.

        > Paul TBBle Hampson wrote:
        >
        > >I'm creating a SOAP service which I want to
        > >username/password protect, against the database
        > >the service modifies.
        > >
        > >It seems to me that the easiest way to do this
        > >would be to have access to the username/password
        > >sent in by the client via HTTP basic auth
        > >available somehow to the eventual perl functions.
        > >
        > >However, I can't see any way to do this.
        > >
        > >Have I missed something important, or am I trying
        > >to do something impossible?
        > >
        > >I'm on the Debian 0.60 package at the moment,
        > >and using the mod_soap (Apache::SOAP mod_perl
        > >handler) method to run, although I can change
        > >that if needed. (I'd _rather_ run it through
        > >Apache2 since I get access it's HTTPS setup
        > >for free that way. ^_^)
        > >
        > >
        > >
        > >
        > >------------------------------------------------------------------------
        > >*Yahoo! Groups Links*
        > >
        > > * To visit your group on the web, go to:
        > > http://groups.yahoo.com/group/soaplite/
        > >
        > > * To unsubscribe from this group, send an email to:
        > > soaplite-unsubscribe@yahoogroups.com
        > > <mailto:soaplite-unsubscribe@yahoogroups.com?subject=Unsubscribe>
        > >
        > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
        > > Service <http://docs.yahoo.com/info/terms/>.
        > >
        > >
        >

        --
        Paul "TBBle" Hampson, on an alternate email client.
      • Byrne Reese
        The same methods are available on the server. Simply instantiate an instance of SOAP::Transport::HTTP::*, access the http_request/http_response elements from
        Message 3 of 8 , May 2, 2005
        View Source
        • 0 Attachment
          The same methods are available on the server. Simply instantiate an
          instance of SOAP::Transport::HTTP::*, access the
          http_request/http_response elements from that instance, and then make a
          call to dispatch_to|with on that instance.

          I make it sould so easy...

          my $server = SOAP::Transport::HTTP::CGI->new;
          my $req = $server->http_request();
          # do something
          $server->dispatch_to(...);

          paul.hampson@... wrote:

          > On Mon, May 02, 2005 at 07:36:03AM -0700, Byrne Reese wrote:
          > > You can't do that in 0.60. Try 0.65.
          >
          > > But you could use mod_auth_mysql or my_auth_postgres which are Apache
          > > plugins which will automatically do username/passsword lookups for you
          > > from a set of Basic Auth credentials.
          >
          > That wouldn't help, as I need to know which record it was that the
          > username/password identified.
          >
          > > http://www.majordojo.com/archives/000636.php
          >
          > This covers the client, but I need to do it in the server-side
          > functions, where I don't actually have any SOAP objects.
          >
          > I can get the SOM by putting something in @ISA, but I can't see
          > how I can use that to get to the HTTP::Request.
          >
          > > Paul TBBle Hampson wrote:
          > >
          > > >I'm creating a SOAP service which I want to
          > > >username/password protect, against the database
          > > >the service modifies.
          > > >
          > > >It seems to me that the easiest way to do this
          > > >would be to have access to the username/password
          > > >sent in by the client via HTTP basic auth
          > > >available somehow to the eventual perl functions.
          > > >
          > > >However, I can't see any way to do this.
          > > >
          > > >Have I missed something important, or am I trying
          > > >to do something impossible?
          > > >
          > > >I'm on the Debian 0.60 package at the moment,
          > > >and using the mod_soap (Apache::SOAP mod_perl
          > > >handler) method to run, although I can change
          > > >that if needed. (I'd _rather_ run it through
          > > >Apache2 since I get access it's HTTPS setup
          > > >for free that way. ^_^)
          > > >
          > > >
          > > >
          > > >
          > >
          > >------------------------------------------------------------------------
          > > >*Yahoo! Groups Links*
          > > >
          > > > * To visit your group on the web, go to:
          > > > http://groups.yahoo.com/group/soaplite/
          > > >
          > > > * To unsubscribe from this group, send an email to:
          > > > soaplite-unsubscribe@yahoogroups.com
          > > > <mailto:soaplite-unsubscribe@yahoogroups.com?subject=Unsubscribe>
          > > >
          > > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
          > > > Service <http://docs.yahoo.com/info/terms/>.
          > > >
          > > >
          > >
          >
          > --
          > Paul "TBBle" Hampson, on an alternate email client.
          >
          > ------------------------------------------------------------------------
          > *Yahoo! Groups Links*
          >
          > * To visit your group on the web, go to:
          > http://groups.yahoo.com/group/soaplite/
          >
          > * To unsubscribe from this group, send an email to:
          > soaplite-unsubscribe@yahoogroups.com
          > <mailto:soaplite-unsubscribe@yahoogroups.com?subject=Unsubscribe>
          >
          > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
          > Service <http://docs.yahoo.com/info/terms/>.
          >
          >
        • Jay A. Kreibich
          ... I would actually say this isn t the way to do this. You are mating application requirements (e.g. the need to have auth/auth info associated with the SOAP
          Message 4 of 8 , May 3, 2005
          View Source
          • 0 Attachment
            On Mon, May 02, 2005 at 01:41:13PM -0000, Paul TBBle Hampson scratched on the wall:
            > I'm creating a SOAP service which I want to
            > username/password protect, against the database
            > the service modifies.
            >
            > It seems to me that the easiest way to do this
            > would be to have access to the username/password
            > sent in by the client via HTTP basic auth
            > available somehow to the eventual perl functions.

            I would actually say this isn't the way to do this. You are mating
            application requirements (e.g. the need to have auth/auth info
            associated with the SOAP transaction) with the particular transport
            option (e.g. HTTP[S]). Even if you never plan on supporting anything
            except HTTP[S], it is the wrong layer to be putting this information
            into. If the auth/auth info is part of the SOAP transaction, it
            should be included in the SOAP message, and not the transport layer.

            There is also the issue that adding HTTP header information is
            difficult, if not impossible, with many existing SOAP libraries
            (SOAP::Lite not included).

            I would suggest you look at SOAP Headers, rather than HTTP headers.

            -j

            --
            Jay A. Kreibich | CommTech, Emrg Net Tech Svcs
            jak@... | Campus IT & Edu Svcs
            <http://www.uiuc.edu/~jak> | University of Illinois at U/C
          • paul.hampson@pobox.com
            ... OK, fair point and well taken. I ve found the @ISA thing that lets me pop the SOM out of @_ at the start of every function, so I m guessing I just call
            Message 5 of 8 , May 4, 2005
            View Source
            • 0 Attachment
              On Tue, May 03, 2005 at 11:12:12PM -0500, Jay A. Kreibich wrote:
              > On Mon, May 02, 2005 at 01:41:13PM -0000, Paul TBBle Hampson scratched on the wall:
              > > I'm creating a SOAP service which I want to
              > > username/password protect, against the database
              > > the service modifies.

              > > It seems to me that the easiest way to do this
              > > would be to have access to the username/password
              > > sent in by the client via HTTP basic auth
              > > available somehow to the eventual perl functions.

              > I would actually say this isn't the way to do this. You are mating
              > application requirements (e.g. the need to have auth/auth info
              > associated with the SOAP transaction) with the particular transport
              > option (e.g. HTTP[S]). Even if you never plan on supporting anything
              > except HTTP[S], it is the wrong layer to be putting this information
              > into. If the auth/auth info is part of the SOAP transaction, it
              > should be included in the SOAP message, and not the transport layer.

              > There is also the issue that adding HTTP header information is
              > difficult, if not impossible, with many existing SOAP libraries
              > (SOAP::Lite not included).

              > I would suggest you look at SOAP Headers, rather than HTTP headers.

              OK, fair point and well taken.

              I've found the '@ISA' thing that lets me pop the SOM out of @_ at the
              start of every function, so I'm guessing I just call ->headers on that,
              and skip happily through that array until I find the custom headers
              I've defined...

              So I guess the main thing is, do I have to worry about namespace
              clashes with other things using the SOAP Headers, or should I just define
              my own namespace? Of course, I'm not too clear on how the latter works.
              >_<

              --
              Paul "TBBle" Hampson, on an alternate email client.
            • Jay A. Kreibich
              ... I though that returned a hash ref, not an array, but you ve got the right idea. This is exactly what I m doing with a large SOAP interface I m building to
              Message 6 of 8 , May 5, 2005
              View Source
              • 0 Attachment
                On Thu, May 05, 2005 at 01:22:39PM +1000, paul.hampson@... scratched on the wall:
                > On Tue, May 03, 2005 at 11:12:12PM -0500, Jay A. Kreibich wrote:
                > > On Mon, May 02, 2005 at 01:41:13PM -0000, Paul TBBle Hampson scratched on the wall:
                > > > I'm creating a SOAP service which I want to
                > > > username/password protect, against the database
                > > > the service modifies.

                > > I would suggest you look at SOAP Headers, rather than HTTP headers.
                >
                > OK, fair point and well taken.
                >
                > I've found the '@ISA' thing that lets me pop the SOM out of @_ at the
                > start of every function, so I'm guessing I just call ->headers on that,
                > and skip happily through that array until I find the custom headers
                > I've defined...

                I though that returned a hash ref, not an array, but you've got the right
                idea. This is exactly what I'm doing with a large SOAP interface I'm
                building to front-end a database we run.

                > So I guess the main thing is, do I have to worry about namespace
                > clashes with other things using the SOAP Headers, or should I just define
                > my own namespace? Of course, I'm not too clear on how the latter works.

                I'm not sure the headers have their own namespace. While they are
                part of the SOAP spec, they aren't actually used by SOAP for
                anything. They are more or less there for your own use and many many
                people use them for auth/auth info. You might want to be a bit
                creative with your header names, just to be sure, but unless you
                define a header in your API or WSDL file, they generally won't be
                there.

                They aren't like HTTP headers where the protocol itself uses a bunch,
                so you have to be careful about clashes with "operational" headers.
                All SOAP headers are user-defined, although there might be a few
                client libs that insert "standard" (by their own definition) headers.

                -j

                --
                Jay A. Kreibich | CommTech, Emrg Net Tech Svcs
                jak@... | Campus IT & Edu Svcs
                <http://www.uiuc.edu/~jak> | University of Illinois at U/C
              • paul.hampson@pobox.com
                ... After futzing around, here s a public record of how I get the headers at the server end, and how I do em in the client. (Non-autodispatch, since I m on
                Message 7 of 8 , May 5, 2005
                View Source
                • 0 Attachment
                  On Thu, May 05, 2005 at 11:57:08AM -0500, Jay A. Kreibich wrote:
                  > On Thu, May 05, 2005 at 01:22:39PM +1000, paul.hampson@... scratched on the wall:
                  > > On Tue, May 03, 2005 at 11:12:12PM -0500, Jay A. Kreibich wrote:
                  > > > On Mon, May 02, 2005 at 01:41:13PM -0000, Paul TBBle Hampson scratched on the wall:
                  > > > > I'm creating a SOAP service which I want to
                  > > > > username/password protect, against the database
                  > > > > the service modifies.
                  >
                  > > > I would suggest you look at SOAP Headers, rather than HTTP headers.
                  > >
                  > > OK, fair point and well taken.
                  > >
                  > > I've found the '@ISA' thing that lets me pop the SOM out of @_ at the
                  > > start of every function, so I'm guessing I just call ->headers on that,
                  > > and skip happily through that array until I find the custom headers
                  > > I've defined...
                  >
                  > I though that returned a hash ref, not an array, but you've got the right
                  > idea. This is exactly what I'm doing with a large SOAP interface I'm
                  > building to front-end a database we run.

                  After futzing around, here's a public record of how I get the headers
                  at the server end, and how I do 'em in the client.
                  (Non-autodispatch, since I'm on perl 5.8.4 and couldn't find the
                  workaround again, after seeing it once.)

                  Server:
                  sub showenv {
                  my $som = pop;
                  my $returnlist;
                  $returnlist = "Username: ". $som->match(SOAP::SOM::header."/login")->valueof. "; password: ".$som->match(SOAP::SOM::header."/password")->valueof. ";";
                  chomp $returnlist;
                  return $returnlist;
                  }

                  Client: (This was the easy part. ^_^)
                  my $soapuser = SOAP::Header->new(name => 'login', value => 'user');
                  my $soappass = SOAP::Header->new(name => 'password', value => 'pass');
                  my $result = $soap->showenv($soapuser, $soappass);

                  This was arrived at largely thanks to a blog posting in the howto
                  link on the soaplite homepage about "forwarding headers" along with
                  a liberal application of Data::Dumper::Simple. ^_^

                  --
                  Paul "TBBle" Hampson, on an alternate email client.
                Your message has been successfully submitted and would be delivered to recipients shortly.