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

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

Expand Messages
  • 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 1 of 8 , May 2, 2005
    • 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 2 of 8 , May 2, 2005
      • 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 3 of 8 , May 3, 2005
        • 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 4 of 8 , May 4, 2005
          • 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 5 of 8 , May 5, 2005
            • 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 6 of 8 , May 5, 2005
              • 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.