Does a button with a remote URL action redirect to the remote host? #47
Labels
No labels
UserStory
bug
duplicate
enhancement
help wanted
hw task
invalid
question
refactoring
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
mattzz/halloween#47
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
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...
What we can do is this:
This is exactly what is being done when one hosts scans other hosts if they are online (see scary_actions.py --> scan_hosts)
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.
Example here: https://stackoverflow.com/questions/14873443/sending-an-http-post-using-javascript-triggered-event
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:
Let's do it that way. The webserver translates the button clicks from the home page to POST requests to the exhibits.
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/laughis made available by eyesinthedark under the following URL
http://eyesinthedark/scary_hosts/weremonkey/scary_actions/laughIn 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 tohttp://[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.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
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.
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.