Forcing Authentication with HTTP Client

[balexand]

I needed a way to force the LabVIEW HTTP Client to send a basic authentication header with a request.  Right now, it appears that the client sends this authentication information automatically after it receives a "401 Authorization Required" status, with the WWW-Authenticate response header indicating "Basic" authentication.  Some webpages might respond with a "200 OK", but with a differently body if the client did not specify an authentication header.  For instance, maybe the body is still valid for anonymous users, but if the client has provided authentication info, you get additional/different information.  It would be really convenient if the HTTP Client supported a public API to "force basic authentication".  Instead, I just had to do it by adding the header manually:

[balexand]

Note that in my example, the password is sent unencrypted over plain text.  Stronger security mechanisms are usually recommended, but the web server needs to support them.

[Evan_S]

Balexand,

It appears you are just posting an example to help out the community and share information, but I just wanted to check to make sure that you didn't have a question on this.

We also have a section in NI Developer Zone which allows you to post examples for the entire community.

http://zone.ni.com/dzhp/app/main

Thanks!

[balexand]

This is mostly just a suggestion:

It would be really convenient if the HTTP Client supported a public API to "force basic authentication"

It's interesting that I was able to get it to work by forcing the "Authorization" header value.  "Authorization" is not even one of the values available on the Combo Box input, because it's supposed to get set by the internal operations of the HTTP Client DLL.  The screenshot shows a dirty workaround, and I am actually surprised it worked.

[DavidBoyd]

Interesting - I had the exact same problem (wanting to force pre-emptive authentication), and proposed solving it exactly the same way.  I just wasn't sure whether adding the Authorization header interfered with, or was overwritten by, the HTTP library VI's own behavior.  It may be that, since cURLlib doesn't see a 401 reply once you supply the header, it never has cause to supply it on its own.

I do wish that the setting at the cURLlib level was exposed by the VI.  Especially since the method described here only works if the server allows Basic authentication.  If it requires Digest or NTLM, this won't work (and worse, may prevent cURLlib from implementing it under the hood for you).

balexand, I hope you're still reading the forums and getting updates - this is a pretty old thread.

Best regards,

Dave

[Kelly_B]

Hi David and balexand, 

I'm glad that you've both found a way to make this work for your applications.  If you would like to propose this as an added feature to LabVIEW, you can post a suggestion on the LabVIEW Idea Exchange.  That board is monitored by R&D and is a great place to propose and collaborate on ideas like this one.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas 

[BMJ]

That worked like a champ! I racked my braintrying to get the "built-in" authentication to work. Totally agree this should be a VI option.

FYI for anyone else that happens upon this, the white subVI is a Base64 encoding function. LabVIEW has a built-in one, but it's not in the palettes. Do a web search and you'll find the path.

[bendixondavis]

BTW, had problems with this code, trying to use token authentication.  Found that using JKI REST Client API worked.  I just added a header for Authorization in the default headers and then used "Token 123456789abcd123" for the value where the junk number I have in the example is the API token.