G Web Development 21.0 Questions

[bhpowell]

I'm trying to use the G Web Development Software 2021 for the first time, and I have some questions.

1) Is this board the right place to ask?  I couldn't find any place more appropriate.  The product has a "Help -> Ask the NI Community" menu item, but it seems to just generically lead to the NI Forums.

2) Open HTTP Handle takes a username and password, but it says these are for an SMTP server.  Does anyone understand what relationship there is between an SMTP server and opening up an HTTP connection in this software?

3) I'm trying to use BasicAuth authorization and was hoping that the username/password mentioned above were somehow related to this.  Apparently not; if I wire in the username/password, no Authorization: header is inserted in the request if I do an HTTP request with this connection.  I think that means that I have to use "Add Header" to add the Authorization: header myself.  Fine; I can do that.  But I need to do a base64 encoding of the username/password combination.  I expected to find something under the String palette for encodings, but I didn't find one.  I mean, is this a valid expectation?  This is for web development, and it's a common operation.  Anyway, does anyone have an implementation of base64 encoding for the G Web Development Software 2021?  Or am I just looking in the wrong place?

Thanks.

[cbutcher]

Re 2., I think these are basically the same as the standard LabVIEW ones - I usually use the Open Handle without any parameters and then go directly to the POST/GET methods to actually do something.

For the authentication, you will need to use the Headers, as you surmised.

I have this in one of my LabVIEW web handlers:

The Base64 encoding VI in use here is from https://forums.ni.com/t5/Example-Programs/LabVIEW-Utility-VIs-for-Base64-and-Base32Hex-Encoding-Usin...

[Christina_R]

---

@bhpowell wrote:

1) Is this board the right place to ask? 

2) Does anyone understand what relationship there is between an SMTP server and opening up an HTTP connection in this software?

3) But I need to do a base64 encoding of the username/password combination. 

---

1) We're planning to create a G Web Development Software forum soon!

2) I filed a documentation bug. It looks like the username/password descriptions were erroneously copied from the LabVIEWSMTPClient.lvlib:Open Handle.vi

3) I've found out that SystemLink installs a base64 encoding function: "C:\Program Files\National Instruments\G Web Development Software 2021\Addons\NI\Skyline\configuration-src\21.1.0\NI.SL.Configuration.gcomp\base64.gvi" Also, Milan Raj has an example with another implementation: https://forums.ni.com/t5/Example-Code/File-for-WebVI/ta-p/4129229 He says it's "a version based on JSLI that calls into the browser built-in base64 encode / decode functions. It's a lot faster (implemented for quickly encoding multi-MB files) but probably overkill for just encoding a username and password."

By the way, Paul Spangler, one of NI's web experts, told me "the username and password inputs for the Open HTTP Handle function are passed along to cURL, which will use them for any HTTP-based authentication, such as basic or digest auth, if the web server responds with a 401 asking for credentials. But browsers these days don't like to allow you to specify a username and password programmatically, so some browsers may ignore it, some may throw up a dialog, and some may use them."

[bhpowell]

Hi, Christina.

Thanks for the pointers to .gvi base64 implementations.  I'll check them out.

On the last comment from Paul Spangler, I was sending a 401 from the web service, and the G Web software complained about Access-Control-Allow-Origin rather than supply the auth.  This was confusing enough and frustrating enough that I just gave up on that for the time being.  I suppose if I figure out the CORS stuff, the HTTP Open might (emphasis on "might") actually do auth for me, but it just seemed easier to go down the path of adding the header myself.  More documentation on what the software wants to see from the 401 response in various scenarios would be helpful.

As background, I'm trying to decide between the G Web software and just putting something together in Javascript.  I don't need much more than a date picker and a graph.  It looks like either way, I'll be cobbling together the pieces I need.

Semi-related, kudos to whoever fixed LV 2021 to use the system certificates!  I got bit by NI's out-of-date certificates in LV 2020 and earlier.

[MilanR]

---

I was sending a 401 from the web service, and the G Web software complained about Access-Control-Allow-Origin rather than supply the auth.

---

If the response to the HTTP Request is a 401, it is a browser-specific behavior of how to respond to the request, not something that WebVIs have defined. Some browsers show a pop-up, some silently ignore the request, some may use the username and password credentials but only in specific cases such as only for same-origin requests or requests over HTTPS, etc.

Adding the Authentication header to the request yourself and not relying on the 401 response behavior of the browser is what many JS applications opt for so if that workflow works with your webservice that may be more reliable across browsers with WebVIs as well.

One thing to be aware of is that adding an Authentication header to the HTTP request changes the request to a credentialed HTTP request. This does not cause issues for same-origin applications but will require modifying the WebVI diagram and modifying the web service for cross-origin applications.

• To verify if the way the WebVI and web service interact is considered same-origin or cross-origin see the topic Considerations When Accessing Data from Web Services.
• If you determine the WebVI and webservice interact in a cross-origin manner then to use the Authentication header you need to modify the WebVI and Web Service to enable credentialed cross-origin requests.
  • For changes to the WebVI to enable credentialed cross-origin HTTP requests see the topic Sending a Credentialed Cross-Origin HTTP Request.
  • If you are using LabVIEW Web Services with the Application Web Server for listening to credentials cross-origin HTTP requests see the topic Configure a LabVIEW Web Service CORS for Credentialed Access.

Hopefully those topics get you on the correct path if you do find yourself needing to handle CORS configuration.

[Christina_R]

The discussion forum for G Web Development Software is now live! 

https://forums.ni.com/t5/G-Web-Development-Software/bd-p/g-web-development?profile.language=en

[bhpowell]

Thanks, Christina.  Is it possible for an admin to move this thread to the new forum?

[bhpowell]

---

@MilanR wrote:

---

I was sending a 401 from the web service, and the G Web software complained about Access-Control-Allow-Origin rather than supply the auth.

---

If the response to the HTTP Request is a 401, it is a browser-specific behavior of how to respond to the request, not something that WebVIs have defined.

---

Thanks, Milan.  That's all very helpful information that I will look through.

I want to make sure I understand the phrase "browser-specific behavior" that you and Christina have used.  I guess I interpret that to mean that functions like HTTP Open, Read, Write, Add Header, etc., are all translated into browser code (such as Javascript), and that's why you can't give a firm answer about how, for example, a 401 response is handled.  Is that correct?

Christina's earlier answer talked about cURL, so I'm trying to reconcile that statement with "browser-specific behavior".  Can someone help sort out my understanding?

[MilanR]

---

@bhpowell wrote:

---

@MilanR wrote:

---

I was sending a 401 from the web service, and the G Web software complained about Access-Control-Allow-Origin rather than supply the auth.

---

If the response to the HTTP Request is a 401, it is a browser-specific behavior of how to respond to the request, not something that WebVIs have defined.

---

Thanks, Milan.  That's all very helpful information that I will look through.

I want to make sure I understand the phrase "browser-specific behavior" that you and Christina have used.  I guess I interpret that to mean that functions like HTTP Open, Read, Write, Add Header, etc., are all translated into browser code (such as Javascript), and that's why you can't give a firm answer about how, for example, a 401 response is handled.  Is that correct?

---

For this example, ie a 401 response to a GET request, the behavior is browser-specific meaning that you may see different behaviors across the major browsers such as Chrome, Firefox, Edge, Safari. Some may show a pop-up ignoring the credentials you gave on the diagram and asking the user for them directly a security measure, etc.

Instead of relying on the browser to handle the 401 challenge, you can use the Authorization header as you described for basic auth which behaves consistently across browsers (and consistently may require CORS based on the previous discussion). That is the approach we use in the Data Services APIs, for example in the NI.SL.Configuration.gcomp:Open Session with Credentials VI which on my machine is located at C:\Program Files\National Instruments\G Web Development Software 2021\Addons\NI\Skyline\configuration-src\21.1.0\NI.SL.Configuration.gcomp\Open Session with Credentials.gvi as seen in the following screenshot:

Many behaviors are well supported across browsers, ie I don't expect behaviors of GET, POST, PUT, Add Header, etc, to behave significantly different across browsers. This case with the username and password options for the HTTP Client case was one where we were aware that providing those values have browser-specific behavior but we opted to expose it through the API to give users the most control.

If you're interested and familiar with the details of the JavaScript-side, the username and password inputs of Open HTTP Handle are mapped directly to the XMLHTTPRequest.open api in JavaScript. If you are deeply interested in the details then it may be interesting to note that the WebVI runtime is open source and you can see the http implementation on GitHub.

---

Christina's earlier answer talked about cURL, so I'm trying to reconcile that statement with "browser-specific behavior".  Can someone help sort out my understanding?

---

This was to provide a comparison between desktop and the browser. In desktop LabVIEW the HTTP Client is powered by cURL which will use provided username and passwords to handle a server 401 response compared to WebVIs where the HTTP Client is powered by the browser and the behavior of responding to a 401 response is browser-specific.