The use for cookiefile, username and password in the HTTP OpenHandle vi

[aartjan]

I have been making some webservices and also accompanying Labview API's that communicate with the webservices. I run the webservices in the NI Web Server (not the application web server).

I thought I could use the credentials inputs on the OpenHandle.vi to do basic authorisation.

However, I can't seem to find what the client handle does with the credentials. When I do a GET or POST, I do not find these creadentials in any request headers. The HTTP toolkit also provides no functions to insert the credentials into a request, or even retreive the data.

I also tried to use a cookie file to store a session cookie. That, too, won't work. I have the login endpoint issue a Set-Cookie header in the response headers. But the cookie isn't stored in the file, nor is the cookie issued in subsequent requests (makes sense if it isn't stored in the first place).

Are these inputs only functional when using the Application Server?

What is the preferred method of autorisation with NI Web Server?

[HorseBattery_Stapleguy]

I don't know if this helps since I haven't used the NI Web Server, nor have I used those inputs before.

I've made calls to the AWS API and others, where they require cookies and specific authorization headers.

In most scenarios, I've found that the authorization information is inside a header or in the query part of the request. If its inside the header, then I just add that header following the requirements of the API, and the necessary contents (Eg. credentials, hashes, tokens, etc. etc.)

Same thing with cookies. I manually add the header and the contents and it works for me. This all appears in the HTTP request.

So you could try that if those inputs don't work for you.

Regarding the credentials inputs in those VIs, as far as I know they're for very basic authentication schemes. I don't think they're very safe, so you're better of following something else unless your requirements are very lax/or your use case is non-sensitive.

[aartjan]

It took me a while to get it error free, but I have implemented setting and reading cookies for the purpose of session tracking and authentication. It works really nice with browsers. Labview (and other) clients must add the cookie header to each request for the server to recognise the (authorized) session. I am implementing a LV client API that takes care of all that.

None of the functionality above uses the inputs from HTTP OpenHandle.vi. Those I completely ignore.

[aartjan]

I finally got it working. Although I use session cookies now, I noticed that the server was handing the client the following header:

WWW-Authenticate: Basic realm="protected area"

The HTTP definitive guide mentions for basic authentication that clients (eg the Labview HTTP client) will issue the authorization header only after it first receives an 401- Unauhorized response. I guess that is why I couldn't get it to work before!!

The HTTP GET vi actually implements this, too: it will first perform a get request without the authorization header and upon receiving a 401 response it will issue another get request WITH the basic authentication header included. It is confirmed by the double header output.

Next I will try and see if I can get it to store the cookie as well.

[aartjan]

I have the cookie working correctly as well. The cookie header is very particular if it comes to formatting. The HTTP session will take care of storing the cookie as long as you define a path in the openHandle.vi. It will also create the file if necessary. The session will also take care of discarding expired cookies.

The cookie is thereafter issued with every HTTP request, which makes it very convenient to track clients over multiple requests (a so-called session cookie) and authenticate the user as well. However, once the browser starts including the basic authentication header (as described in my previous posting), it will keep on doing so over all requests as well!

If you do not want the client including your credentials in every request of the session, you basically have to first do an HTTP session to acquire a session cookie (with persistency parameter set) and then start a new HTTP session that uses the cookie header to authorize.

[Matt14122017]

Hello aartjan,

I am after something like this. What i am wanting to acheive is when a client logs in through a web page using username and password i want to collect the session id and use thta so that the client can get there data from a table that as numerous data from diffrent clients.

would it be possible for you to allow me a copy of the vi's that you have created.

Kind Regards

Matt

[aartjan]

Matt, there are not really custom VIs involved. I mostly explained (to myself) what the use is of the authentication and cookie inputs on the OpenHandle.vi. It is very important to realize that these inputs can only be used for servers that support the basic authentication protocol. I read that this protocol is not really acceptable anymore for public servers, even if the connection is TLS encrypted. It is something you have to contemplate if you make your own webservice/server application.