Does a button with a remote URL action redirect to the remote host? #47

Closed
opened 2018-10-12 11:34:56 +02:00 by mishi · 10 comments
mishi commented 2018-10-12 11:34:56 +02:00 (Migrated from git.mattzz.de)

I have implemented a button with a remote scary action URL.

For starters, a post didn't work like it does with the local URL. I got a 405.

However, I realised while trying it that the post redirects to the destination of the action. For example: On Eyes-in-the-dark I press the Weremonkey laugh button and this automatically takes me to the Weremonkey.

Question: Do we want that? Like this we would not have a central page that it hosted on one Master RPi but we would jump from one RPi to the next. Maybe we have to consider using Javascript for the button press POSTs. Then we can just ignore the response.

For now, I have implemented a GET because the POST doesn't work. With the GET it's same behaviour.

I have implemented a button with a remote scary action URL. For starters, a post didn't work like it does with the local URL. I got a 405. However, I realised while trying it that the post redirects to the destination of the action. For example: On Eyes-in-the-dark I press the Weremonkey laugh button and this automatically takes me to the Weremonkey. Question: Do we want that? Like this we would not have a central page that it hosted on one Master RPi but we would jump from one RPi to the next. Maybe we have to consider using Javascript for the button press POSTs. Then we can just ignore the response. For now, I have implemented a GET because the POST doesn't work. With the GET it's same behaviour.
mattzz commented 2018-10-12 21:40:16 +02:00 (Migrated from git.mattzz.de)

The laugh button's action is a GET on "http://weremonkey/laugh".

Maybe we have an issue with this whole idea of the main page calling remote URL via POST and then staying on the master pi (whichever that is at that moment).

Because once we POST or GET an action that very page (on the remote host) will be called by the browser.

Hm. Need to think about that. Maybe we can redirect to the requesting host...

The laugh button's action is a GET on "http://weremonkey/laugh". Maybe we have an issue with this whole idea of the main page calling remote URL via POST and then *staying* on the master pi (whichever that is at that moment). Because once we POST or GET an action that very page (on the remote host) will be called by the browser. Hm. Need to think about that. Maybe we can redirect to the requesting host...
mattzz commented 2018-10-12 22:42:52 +02:00 (Migrated from git.mattzz.de)

What we can do is this:

  • Button submits a POST action to localhost
  • On localhost the POST route evaluates the action and submits a direct request to the remote hosts.

This is exactly what is being done when one hosts scans other hosts if they are online (see scary_actions.py --> scan_hosts)

What we can do is this: - Button submits a POST action to localhost - On localhost the POST route evaluates the action and submits a direct request to the remote hosts. This is exactly what is being done when one hosts scans other hosts if they are online (see scary_actions.py --> scan_hosts)
mishi commented 2018-10-12 22:58:25 +02:00 (Migrated from git.mattzz.de)

I think it would be better if the button triggers a Javascript that 1) disables the button, 2) posts the command to the remote URL and then when done 3) just enables the button again.

I think it would be better if the button triggers a Javascript that 1) disables the button, 2) posts the command to the remote URL and then when done 3) just enables the button again.
mishi commented 2018-10-12 23:00:52 +02:00 (Migrated from git.mattzz.de)
Example here: [[https://stackoverflow.com/questions/14873443/sending-an-http-post-using-javascript-triggered-event]]
mishi commented 2018-10-13 00:14:10 +02:00 (Migrated from git.mattzz.de)

Your proposal sounds good after all. I've just tried sending a POST request from JS but it is stopped by security mechanisms (CORS) and it's not good to shut off those mechanisms.

Here's the code that I've tried but which leads to the CORS error:

<script>
	function weremonkey_laugh() {
		var url="http://weremonkey/laugh";
		var method="POST";
		var postData = "Some data";
		var shouldBeAsync = true;
		var request = new XMLHttpRequest();
		request.onload = function () {

		   // Because of javascript's fabulous closure concept, the XMLHttpRequest "request"
		   // object declared above is available in this function even though this function
		   // executes long after the request is sent and long after this function is
		   // instantiated. This fact is CRUCIAL to the workings of XHR in ordinary
		   // applications.

		   // You can get all kinds of information about the HTTP response.
		   var status = request.status; // HTTP response status, e.g., 200 for "200 OK"
		   var data = request.responseText; // Returned data, e.g., an HTML document.
		}

		request.open(method, url, shouldBeAsync);
		request.setRequestHeader("Content-Type", "text/plain;charset=UTF-8");
		// Or... request.setRequestHeader("Content-Type", "text/plain;charset=UTF-8");
		// Or... whatever
		// Actually sends the request to the server.
		request.send(postData);
		document.getElementById("demo").style.color = "red";
	}
</script>
<input type="button" value="Weremonkey Laugh JS" onclick="weremonkey_laugh();"/>
Your proposal sounds good after all. I've just tried sending a POST request from JS but it is stopped by security mechanisms (CORS) and it's not good to shut off those mechanisms. Here's the code that I've tried but which leads to the CORS error: ``` <script> function weremonkey_laugh() { var url="http://weremonkey/laugh"; var method="POST"; var postData = "Some data"; var shouldBeAsync = true; var request = new XMLHttpRequest(); request.onload = function () { // Because of javascript's fabulous closure concept, the XMLHttpRequest "request" // object declared above is available in this function even though this function // executes long after the request is sent and long after this function is // instantiated. This fact is CRUCIAL to the workings of XHR in ordinary // applications. // You can get all kinds of information about the HTTP response. var status = request.status; // HTTP response status, e.g., 200 for "200 OK" var data = request.responseText; // Returned data, e.g., an HTML document. } request.open(method, url, shouldBeAsync); request.setRequestHeader("Content-Type", "text/plain;charset=UTF-8"); // Or... request.setRequestHeader("Content-Type", "text/plain;charset=UTF-8"); // Or... whatever // Actually sends the request to the server. request.send(postData); document.getElementById("demo").style.color = "red"; } </script> <input type="button" value="Weremonkey Laugh JS" onclick="weremonkey_laugh();"/> ```
mishi commented 2018-10-13 00:21:02 +02:00 (Migrated from git.mattzz.de)

Let's do it that way. The webserver translates the button clicks from the home page to POST requests to the exhibits.

Let's do it that way. The webserver translates the button clicks from the home page to POST requests to the exhibits.
mishi commented 2018-10-13 11:54:49 +02:00 (Migrated from git.mattzz.de)

Having in mind the RESTful discovery approach for the scary_actions an exhibit could offer a resource "scary_hosts" with the list of available hosts. Under each host you find exactly the scary actions that a host offers when you access it directly.

Example:

Weremonkey's scary action "laugh"

http://weremonkey/scary_actions/laugh

is made available by eyesinthedark under the following URL

http://eyesinthedark/scary_hosts/weremonkey/scary_actions/laugh

In this case - like you suggested - eyesinthedark would translate the POST to the localhost URL to a POST to the remote host URL.

Maybe as a first step, the implementation of the scary_hosts resource does not even have to know which hosts and scary actions are available. A handler for /scary_hosts/[remote_url] which just generates a POST to http://[remote_url]. There is then no need for implementing the GET on the scary_hosts or scary_actions resources for discovering the available hosts or actions, respectively.

Having in mind the RESTful discovery approach for the scary_actions an exhibit could offer a resource "scary_hosts" with the list of available hosts. Under each host you find exactly the scary actions that a host offers when you access it directly. Example: Weremonkey's scary action "laugh" ```http://weremonkey/scary_actions/laugh``` is made available by eyesinthedark under the following URL ```http://eyesinthedark/scary_hosts/weremonkey/scary_actions/laugh``` In this case - like you suggested - eyesinthedark would translate the POST to the localhost URL to a POST to the remote host URL. Maybe as a first step, the implementation of the scary_hosts resource does not even have to know which hosts and scary actions are available. A handler for ```/scary_hosts/[remote_url]``` which just generates a POST to ```http://[remote_url]```. There is then no need for implementing the GET on the scary_hosts or scary_actions resources for discovering the available hosts or actions, respectively.
mishi commented 2018-10-13 13:35:34 +02:00 (Migrated from git.mattzz.de)

Here are the URLs resulting from that. As mentioned, the GETs are not needed until later when we go for the dynamic discovery: https://mattzz.no-ip.org:3000/mattzz/halloween/wiki/Web-API#generic-api

Here are the URLs resulting from that. As mentioned, the GETs are not needed until later when we go for the dynamic discovery: [[https://mattzz.no-ip.org:3000/mattzz/halloween/wiki/Web-API#generic-api]]
mishi commented 2018-10-17 00:52:20 +02:00 (Migrated from git.mattzz.de)

A redirection method is implemented now in pumpkin.py for route /scary_hosts/// that redirects to http://scary_hosts///

Example: http://cocoonman:5000/scary_hosts/eyesinthedark:5000/scary_actions/roar

So far only tested with GET.

A redirection method is implemented now in pumpkin.py for route /scary_hosts/<host>/<activity>/<action> that redirects to http://scary_hosts/<host>/<activity>/<action> Example: [[http://cocoonman:5000/scary_hosts/eyesinthedark:5000/scary_actions/roar]] So far only tested with GET.
mishi commented 2018-10-18 00:50:02 +02:00 (Migrated from git.mattzz.de)

Done. The approach now also works with POST. There are now two buttons in index.html, one for weremonkey's laugh and one for eyesinthedark's greet.

Done. The approach now also works with POST. There are now two buttons in index.html, one for weremonkey's laugh and one for eyesinthedark's greet.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
mattzz/halloween#47
No description provided.