When the http header
Authorization: Basic is set and sent, the username and password combination is first concatenated
with a separating colon in between (username:password) and then base64 encoded, resulting in a somewhat cryptic value that is non-the-less easily translated back into its parts.
You can use any base64 encoder. You can also find sites online that will encode and decode base64 for you, if it’s a one-off.
This is all specified in RFC 7617 and RFC 4648
https://en.wikipedia.org/wiki/Basic_access_authentication
https://en.wikipedia.org/wiki/Base64
Fra: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx]
På vegne af Don Brown
Sendt: 13. juli 2019 05:04
Til: web400; ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Emne: [Ftpapi] Basic authentication to web service and Postman
I am hoping someone can assist/advise as I am a little puzzled
We are working on a new project and using Postman to test web service calls and then this will be coded in RPG and use HTTPAPI.
In Postman we have set up the Authorization as "Basic Auth" and specified the values for User name and Password
When we "Send" the Get request it work ... Great! But then looking at the generated HTTP I am confused as it appears the basic authorization has been converted to an authorization string
Can anyone advise how this conversion is done or why I am not seeing a User name and Password details in the header ?
GET /sydney/drivers?id=16551 HTTP/1.1
Host: sydney-api.icabbi.com
Authorization: Basic ZWUyNTU1NmJkM2U5ODhiMTRjM2YyMmFmMDc3MzllODljNWJkY2YwNjo2NzExZmJlZTM5YTNjY2ZjYmI2MjljYzI0M2ZhNzQ0MzQ5MjFhNjNh
User-Agent: PostmanRuntime/7.15.2
Accept: */*
Cache-Control: no-cache
Postman-Token: 7862a43b-82d4-408c-aee3-01ccba1daea0,5cd17cca-f6e3-4c3f-b653-ccbf6267d53d
Host: sydney-api.icabbi.com
Accept-Encoding: gzip, deflate
Connection: keep-alive
cache-control: no-cache
Don Brown
______________________________________________________________________
This email has been scanned for computer viruses. Although MSD has taken reasonable precautions to ensure no viruses are present in this email, MSD cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
______________________________________________________________________