Is there a way to keep a webpage in a loading state?
I thought of sending resource request to web server and making the web server not send anything back. However I would like to find a solution that can be controlled from the client side.
Related
I've written a game server in python which communicates to multiple pygame clients via sockets. Since it's a turn-based card game there isnt that much data flowing and it's in JSON format. Because I don't want people having to download the client I've started working on a 3D UI with three.js and it's not looking bad.
However I am currently stuck with the communication between the backend (my python game server) and the frontend (The webpage / client I am building with html, javascript and three.js). I feel like my question is already pretty specific and don't get any helpful results when looking online.
How can the webpage (client) and the python server communicate? What changes do I need to make on the python server side? And what do I need to know to implement this on the client side in javascript?
Because your client is running in a web browser, your main limitation is what the browser supports. Javascript in browsers is severely limited so that a website can't trick computers that visit the website into doing bad stuff.
So the first step is to find out "How can my Javascript web page communicate with a backend at all?" and then once you have chosen something, write the backend after that.
You have two options: HTTP requests (AJAX) or websockets.
An HTTP request is basically the same way the browser downloads the page to begin with, and the pictures on the page. The browser says to the server "hey, give me the address http://127.0.0.1:8000/play_card?card_number=3 and the server says back "the page says OK". Little does the browser know, that your server made you play card number 3 and now it's the next player's turn.
This is one-way - the client can ask for stuff, the server can't just send it. So the client has to keep asking over and over, whether anything has happened. The client might ask for address http://127.0.0.1:8000/game_status?player=5 and maybe the server says {} if nothing has changed. (Or maybe it says the entire game status and then you don't need the player number. Depends on the game.)
The other option is websockets. The browser sends a special request saying "hey please make this connection into a websocket" and the server sends a special response saying "okay, this connection is now a websocket", and then the connection stays open for as long as the client wants, and the client and server can send data at any time. It's not just a normal socket, though, because there are extra security measures to prevent the webpage from doing naughty stuff. And the connection always starts with an HTTP request and response.
In either case, note that http://127.0.0.1:8000 has to be the same website that the web page came from - websites can't just send requests to other websites (that would be naughty), so your server also has to serve the game page itself. (not difficult)
You can implement HTTP and/or websockets yourself by listening on a socket on port 8000 (or any other port), but you'll have to learn the HTTP protocol and get it right or else it won't work. It's actually not too difficult but it is work that you have to do. Or you can use a library someone else wrote, like http.server or websockets.
I have a C# server side web service. but I don't want user can to see my requests like request tab from client's browsers.
now, I haven't been find any solution on SO.
what is the best solution to do this?
I think I can use a node.js server-side and render my reactjs inside it and my node.js send my requests to C# server side. like this:
React.js<--(render)--Node.js--(Send/Receive api's)-->C#
I don't know if I use a node.js server, my requests will be hidden from clients?
I don't want to use reactjs.net.
If you're making a HTTP request to node server, and making the stealth request from NodeJS to another server, that request will not be visible to the client.
Alternatively, you can make an encrypted request. Although URL and some part of encryption algorithm will still be exposed at client's end.
I'm working on an SDK type thing for submitting data (including file uploads) to a service that I run.
I'm doing research, and trying to figure out the best way to submit data and get a response to an external server (my server) without being blocked by XSS restrictions.
The current setup is as so:
The customer hosts a server, and uses my server side library.
They generate a client page that loads the required JS from my server.
The client page requests data from my server (if it was not passed from the SDK on page load), and displays the information to the user.
The user then triggers an event, which submits data (potentially including file uploads) to my server (not the local server with the SDK library).
My server responds success or fail and the client JS handles it appropriately.
Some notes:
My server is a private PHP server that I have complete control over.
Although I could route all data through the customer's server (as they are using my library), it is not ideal, as it requires more set up for the customer, is slower for the end user, and handling file uploads is problematic as I want those files on my server, not theirs.
I thought perhaps the file upload inputs could be in an iframe. Will this allow uploads direct to my server?
Since the customer is using my library with an API key, I can authenticate the client's requests by passing an authentication token to the front end on page load that then gets passed to my server with whatever communication method ends up working.
I am open to changes in the architecture, but this is the ideal set up for me. I am just not sure what frontend methods are best for implementing this.
JSONP would work if you only need to make GET requests, but it sounds like you need to do POSTs as well since you mention file uploads.
For your case, Cross-Origin Resource Sharing (CORS) might work. The short explanation is that a browser will send an extra header named Origin if you make a request with XMLHttpRequest to another domain. Your server needs to respond with an additional header named Access-Control-Allow-Origin with a value of * or the value the browser sent in the Origin header. There are some nuances and gotchas when using CORS, so I recommend reading the link above for a thorough explanation.
With CORS set up, you should be able to use XMLHttpRequest to upload files.
I have the following situation: A frontend server redirects with HTTP Post to a backend server. At entry of the backend server, I execute some PHP code before the page has been loaded. I would like to send a notification, at this point, back to the frontend server that the redirection was successful.
The entry page on the backend uses the Post/Redirect/Get pattern to prevent browser form resubmission alert, so after this the PHP code does a HTTP Get request to itself. After the Get header has been sent, the notification back to the frontend should not be sent from PHP code, to prevent sending it each time the page is refreshed on the backend server.
Can this be done from PHP code, or do I have to wait until the document has loaded and then use an Ajax call from Javascript and somehow check that the notification is only sent once (the first time)?
After all processing was complete, your backend server could redirect back to the front-end server, with any custom data to be passed either as POST vars or url parameters in a GET. The front end server would then handle the UI display of this custom data.
But I think thats a sloppy design... systems should be segregated not just for security reasons, but also for scalability. The best design IMHO would be to make bi-directional AJAX calls between your "frontend" web server to a firewalled, "backend" system.
Imagine I have a public display, showing a browser displaying a web page.
Is it possible to send a GET or POST from a mobile device to an HTTP server which triggers some AJAX/pubsub/websocket JavaScript function that changes the page that is presently being viewed on the display, or even just changing an iframe's current domain?
Cross-domain pushstate? Is this at all possible even on your own setup?
Assuming you control the web page being shown on the public display, yes.
The web page would need to either periodically contact the server via AJAX, or have a long-running connection to the server (i.e. Comet or WebSockets).
When the server receives the request from the mobile device, it either uses the Comet connection to send the new URL to the web page, or when the web page next contacts it via AJAX, it sends the new URL in response.
The web page then sets its own window.location property to this new URL.
Note that once it's done this, you'll no longer be able to send the browser in question to another new page, unless the page that you've just sent it to also includes the JavaScript that contacts your server.
But if you don't control the web page being displayed...
Then you'd need a browser extension to initiate the connection between the browser and your server.
You can do this with JavaScript on the client side. This is covered pretty well in that question: Updating address bar with new URL without hash or reloading the page
Unfortunately, it's a relatively new, and mostly unsupported feature. Your alternative is to set the hashtag and use it for navigation.
UPDATE:
If you are trying to "push" pages to the user like a TV channel, then you can have an AJAX request poll the server every few seconds to see if there's a new page. The server would respond with the new URL. You could then put that page in an iFrame.