0

We have a web application that is accessed via kiosk workstations. We are looking for a way to track usage of each individual kiosk. Using the IP address was our first thought, but we quickly realized this wouldn't work since these particular machines are behind networks with dynamically allocated IP addresses.

To accomplish this it was suggested that we create a simple application that can run as a startup service on each machine. This service would then create a cookie containing a unique identifier and save it in the cookies directory of the web browser being used.

From then on each request sent to the web application would send the cookie containing the identifier, allowing for the web application to track the exact machine making the request.

Should this be done this way? My first instinct is to say no, or if it is, it shouldn't be done because a browser should remain sand boxed from the environment it's running in...right?

Improve this question

1 Answer 1

Reset to default
1

Can't you just set up an API path in your web app to track usage info? In my web app I have a path to start and stop session tracking for our lab's computers. The web app expects a username and creates a new tracking record.

We have a simple script that runs on login - it gets the username of whoever is logged in and POSTS to /tracking/start. It works well, and the script is managed via a Remote Desktop deploy. On logoff, another POST is made to /tracking/stop.

I think it's a much simpler solution to persisting cookies. It would also (probably) require a bit less code.

Improve this answer
4
  • I agree with you, however, this must be accomplished without a login :( Commented Jul 5, 2016 at 16:40
  • @nullReference I just have my script run every time someone logs in, but your could have your script run when the machine is booted, or when whatever your 'session' is started. I suppose that really it depends on your use-case: does the information need to be sent once per session? Or with every page load of your web app? If it's the first, you can write a script to post the information to your server - if it's the latter, a cookie is probably your best option. Then again, if your web app needs to send information back to the kiosk, use cookies, because that's what they were intended for! Commented Jul 5, 2016 at 17:30
  • I'm afraid it's the latter. I'm tossing around the idea of having a simple batch script that is run on boot that starts the web browser and loads the url for the web app, passing the unique identifier via GET or POST. Then the web app can look for that particular variable and if it exists then create the cookie that is saved in the browser. This would circumvent the issue of modifying a browsers cookie data with an external program. Commented Jul 5, 2016 at 17:47
  • @nullReference Yeah you can definitely start the browser on bootup and navigate to the necessary URL, then close the browser. It could be something like /startsession that, on the server, just sets the necessary session variables, and you could have JavaScript on that page close the browser instead of your boot script closing it. That way, your server knows that a kiosk booted up, and you kiosk knows what information the server wants on every request. Commented Jul 5, 2016 at 18:12

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.