Design login page

[meysam_b]

Hello community,

I am designing a login page for an application using G web development and I am using websocket to communicate with the server. My question is that I have no idea about the secure design of the login page, that is, what should be done after designing and receiving the username and password from the user and sending it to the server and after getting the result about the login permission? How do I use standard access management methods? How can I find out if the user is logged in and manage access to different parts of the software? How can I work with cookies?
how can I use Microsoft identity platform?
Please take me some basic information

Thanks.

[IlluminatedG]

Anything that runs via programming in G Web and therefore runs in the client browser is not secure. The only thing that could be seen as secure about it is if the user doesn't know how to use a browser's developer tools and inspect / manipulate the page. G Web runs a bit more obfuscated than most websites but it doesn't count as "secure" for anything that would be public facing. If you need any kind of traceability and actual security that is always accomplished via a backend server and not in G Web itself. If you're building a site for a single company's internal use and you just need to provide specific experiences to specific people and crafty people isn't a concern then you can get away with some basic state management in the G Web app.

If you need more security, a typical approach is to have the server provide some kind of token (session, API, etc depending on the server auth mechanisms) that any further requests to the server could include the token and the server would validate that the token is still valid. In short, most of the things you're asking about all happen server side and not in G Web itself.

G Web doesn't provide access to cookies. You would need to do some JSLI wrappers to call javascript code that can work with local storage / cookies. Alternatively, if you're doing GET and POST requests to your server, the server could handle the cookies on server side that a browser would automatically include in any further requests to the same server and that's typically how things like user sessions are managed.

Outside of using the authentication mechanisms built into NI Web Server that limit access to G Web Apps up front, if you don't already have experience with building/using authentication for websites then this will be an arduous path to tread. G Web is designed to build relatively simple data display and control applets and venturing beyond that is going to be a bunch of manual effort.

[meysam_b]

Thank you for your clear reply. You are right and I will make some predictions on the server side to secure the connection. But according to the nature of web-based applications, I think they (G web developers) should consider implementing access management tools. I think the G web idea is greater than a web-based test platform. We can use it for developing a monitoring system, so in future we will need some advanced features. We have some experience of using Grafana tools. These types of monitoring platforms are rising fast today.

[MilanR]

Outside of using the authentication mechanisms built into NI Web Server that limit access to G Web Apps up front

---

I think they (G web developers) should consider implementing access management tools.

---

Just to emphasize in-case it is useful for the application, G Web Development software does include a path for providing access management for Web Applications. If you leverage the services included with G Web you can achieve those kind of workflows out of the box and alternatively you can pick and choose the pieces of G Web that are useful but then may have to build out more of those workflows yourself.

The out-of-the-box / expected workflow of G Web Development Software looks like the following:

• You create a Web Application UI for your application in G Web Development Software. The Web UI can use simple logic client side for some tasks but for complex tasks / controlling hardware, etc, will need to talk to a backend.
• The Web Application UI uses the Tags and Messages API for talking to the backend.
• The backend is a LabVIEW application that uses tags and messages. It can be any type of LabVIEW application that is able to talk to the Tag and messages such as a desktop application that is a running test system or a LabVIEW Web Service running as a service with a main diagram that observes tags and messages. (In reality it can be any type of backend that can make secure HTTP requests like python, .net, etc.)

This affords you some flexibility:

• If you want secure access over the public internet, the tags and messages that the UI is reading and writing to are hosted on SystemLink Cloud. You also likely host the Web Application UI on SystemLink Cloud.
• If you don't want access over the public internet, the tags and messages can be published to a local NI Web Server. You also likely host the Web Application UI on a local NI Web Server.

How access control works in these workflows:

• SystemLink Cloud
  • Tags and messages are associated with an account.
  • You can upload Web Application UIs and make sure they have access to just specific Tags and Messages based on the name of the Tag / Message
  • You can give access to those Web Application UIs to specific users.
  • Your LabVIEW application can read and write to those Tags / Messages knowing only specific Web UI applications (and therefore the users given access to those UIs) have access to those Tags and Messages.
  • Summary: Privileges are determined by users that have access to a specific UI and therefore the tags / messages that the UI can manipulate.
• Local NI Web Server
  • Tags and Messages are associated with an NI Web Server's default workspace.
  • You can upload Web Application UIs to the default workspace that all users that have permissions to view web applications on the NI Web Server can see.
  • You can give access to specific Tags and Messages to specific roles which are groups of users.
  • Your LabVIEW application can read and write to those Tags / Messages knowing only specific roles have access to those Tags and Messages.
  • Summary: Privileges are determined by roles (assigned to specific users) that have access to a specific tags / messages that the Web UI can manipulate.
• Note the subtle difference in the two approaches results in the same end result. The out-of-the-box approach for privileges of data / actions can be controlled by managing access to tags / messages more so than UIs.

How to integrate with Windows login on the NI Web Server:

• Use the Authentication Settings of the NI Web Server to define users. See the Choosing an Authentication Setting topic.
• Assign the users to roles and associate roles with tags and messages.

If that kind of workflow sounds useful for your application or you want a more complete overview of the different ways you can use G Web to make a Web Application I'd recommend going through the How to Build a Web UI for Your LabVIEW-Based Test System presentation and try experimenting with the demos.