× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



* I went through the links provided and while relevant for web page/directory access I was unable to understand how this would apply to a web service on IBMi using the IWS server.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication
https://security.stackexchange.com/questions/755/how-does-basic-http-auth-work


You send an http request (over TLS only) with your credentials. They are "funny", it's user:password encoded in base64

In https://datatracker.ietf.org/doc/html/rfc7617 we read the following where the client has requested some URL and the server response is a 401 (Unauthorized) and a WWW-Authenticate header:


In the example below, the server prompts for authentication in the
"foo" realm, using Basic authentication, with a preference for the
UTF-8 character encoding scheme:

WWW-Authenticate: Basic realm="foo", charset="UTF-8"

Note that the parameter value can be either a token or a quoted
string; in this case, the server chose to use the quoted-string
notation.

The user's name is "test", and the password is the string "123"
followed by the Unicode character U+00A3 (POUND SIGN). Using the
character encoding scheme UTF-8, the user-pass becomes:

't' 'e' 's' 't' ':' '1' '2' '3' pound
74 65 73 74 3A 31 32 33 C2 A3

Encoding this octet sequence in Base64 ([RFC4648], Section 4<https://datatracker.ietf.org/doc/html/rfc4648#section-4>) yields:

dGVzdDoxMjPCow==






Reschke Standards Track [Page 6]

________________________________


RFC 7617<https://datatracker.ietf.org/doc/html/rfc7617> 'Basic' HTTP Authentication Scheme September 2015


Thus, the Authorization header field would be:

Authorization: Basic dGVzdDoxMjPCow==

Your API coded in, let's say, RPG under IWS Application Server never hears the news: the Apache HTTP server that serves your IWS Application Server content intercepts the HTTP headers and says yea or nay, either passing along a request or denying it for lack of authorization.


*
As I have minimal knowledge in this area I may be mis understanding implementing authority for a web service in the apache directives.

Your IWS services are served up over an Apache HTTP server, so it's natural to use Apache directives as long as you use TLS (because the credentials are not encrypted, just base64 encoded).


*
Also while I would be thrilled to attend your session at PowerUp the travel cost and current exchange rate from Oz to US has put this out of my reach - Maybe you can share your presentation :-)

Sad to miss meeting you and chatting! Presentation will be posted with COMMON as usual. Let me know if you have trouble getting at it after the conf.

Jack

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.