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

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

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