So basically I have a Spring Rest Controller that returns an object. I call the method from my JS file to retrieve data and it works great. I know I can hide certain data and stuff but is there a way that I can hide the data showing in the browser. What I mean by this is that when I call the method from my browser and not the js file it shows a blank html page with the JSON output of the object. I would like to hide it from the browser view.
Browser is actually the one who is sending the request for you. It adds request headers, compression etc on your behalf so their is no way you can hide your payload from browser. That's the way web work, if you want some essential details not to be read when response packets travel either encode-decode or encrypt-decrypt your response and use HTTPS.
Related
I'm trying to scrape a website created with the ICEfaces web framework via a node.js script. I've managed to handle the login just fine, and then get some data from the main page (namely ice.session and ice.view, along with the JSESSIONID cookie returned by the login response).
The problem I've run into is when I try to do an AJAX POST request to the /block/ URLs. If I do the request by itself, it returns some data (just not the data I need), but if I do it after any other request, I get <session-expired/> as a result. It doesn't even matter which of the ICEfaces /block/ URLs I send the request to (I've tried with /send-receive-updates, /dispose-views, and even /ping). I've even tried the same request twice in a row just for kicks, and I always get a <session-expired/> response in return on the second one. I've monitored the requests when I browse the page with Chrome, and as far as I know I'm sending all the correct form data (as well as the correct headers). The page works just fine when I load it in the browser, so there must be something I'm not doing right.
Apparently, the order in which you do the requests matters in ICEfaces (i.e. it's not stateless, which kind of makes sense I guess). I just moved the requests around and finally got the response I desired.
IceWindow, IceView and ViewState
Need to be passed as a parameter whenever you do an ajax submit.
Managed bean takes the previous instance of the current view view using ViewState value.
I followed the example on http://docs.brightcove.com/en/video-cloud/media/references/reference.html#Video. The response gets shown in an iframe. However, I would like to be able to get the JSON response in order to store the data (i.e., Brightcove video ID) in my own database. I tried using AJAX post but Brightcove doesn't seem to accept post requests from a different origin. Is there a way to simply get the response data without displaying it in an iframe or in a separate window?
You can't get the response data in javascript since the API response does not include CORS headers. You'd need to do this in server-side code, which also has the advantage of not exposing your API token to the browser.
Is there a way that a MVC Action, initiated by an AJAX request, can redirect the response directly to another page/View without sending a JavaScript “window.location=…” to the client first? In other words, directly transferring the response on the server side and avoiding the roundtrip to the client.
This is a more general question about the possibility to transfer directly an AJAX call, but here is a more specific scenario:
The browser sends an AJAX request to the server and based on the request data the controller's logic performs some operations.
For the majority of the cases, the controller needs to return back a result (JSON) to the same page. However, for few cases it needs to redirect to another page and it returns back a script to redirect the page, but this causes another roundtrip to the browser. The flow is: Page – Server – Page – Server – New Page, and the question is if this can be optimized to Page – Server – New Page .
This isn't really possible, no.
The browser has two options to choose between:
Go to a page
Make an AJAX call to a page
It can't make an AJAX call and automatically redirect based on what the server decides because the client (browser) doesn't know what the server has decided on before the response is even received by the browser.
The traditional approach (which you're avoiding) is:
The browser makes an asynchronous request to the server
The server responds with data informing the client to redirect
The client makes a new request to the server via window.location
The server responds with the new page
However you want to skip a step by doing:
The browser makes an asynchronous request to the server
The client makes a new request to the server via window.location
The server responds with the new page
But the client doesn't know that it needs to redirect and/or it doesn't know how to.
One (ugly) possibility
One idea that comes to mind to pseudo-achieve what you want is to have MVC render the required view and send the whole thing back to the client via JSON rather than a redirection approach. Let me explain.
The browser makes an asynchronous request to the server
The server determines which page needs to be displayed and renders the view (Generating a view without a controller in MVC)
The server serialises the resulting HTML as JSON
The client receives the JSON, and re-renders the entire page with the new markup (i.e. completely replace)
You can also alter the URL and history of the browser to make it "feel" like a redirect by manipulating the browser history.
However I would like to point out that this "solution" is more of an amusing/interesting approach. This isn't really a good way to go about the problem.
I know how to use ajax for submitting a form and all. What I am concerned about is, what is actually happening in the background when a form is submitted via ajax.
How are the values transferred? Encrypted or not? And what is the
need of specifying submission type, I mean get or post, if the URL is
not showing the form fields?
Edit: Found this on w3schools:
GET requests can be cached
GET requests remain in the browser history
GET requests can be bookmarked
GET requests should never be used when dealing with sensitive data
GET requests have length restrictions
GET requests should be used only to retrieve data
POST requests are never cached
POST requests do not remain in the browser history
POST requests cannot be bookmarked
POST requests have no restrictions on data length
How do these apply to ajax form submission?
Basically, when you Ajax-submit a form, it is doing exact same thing as what would happen when you as a user GET or POST submit a form - except that it is done in an asynchronous thread by the browser - i.e. called XMLHttpRequest.
If you submit form as a GET request, all of the form values are stitched together as parameter strings and appended to the URL (form's ACTION URL) - prefixed by a ?. This means anyone who can intercept that communication can read the submitted form data even if request is sent to a HTTPS URL. The POST method sends form data as a separate block (from the URL) and if URL is HTTPS then form data gets encrypted.
It looks like you are just starting out in the world of web development - welcome to the world of programming. I would recommend reading up on some good web development/programming books (I don't want to promote any particular book here). Amazon may help suggest few good ones under "Web Development" kind of search terms.
Also, I suggest that you read up a little on GET vs. POST by googling for it (I can only include one or two links - google will show you hundreds).
For the clear understanding & behind the scene things please refer the links given below.
http://www.jabet.com/
How does AJAX work?
Actually ajax request is same as the normal requests at the server end.
GET or POST has their own use cases. for example: GET has a limit of data transfer depending on the browsers from 1KB to 10 KB. where POST has no such limits.
For a server both AJAX & normal request both are same. so it depends on server code which method you wish to support.
ajax requests are NOT encrypted.
http://www.w3schools.com/tags/ref_httpmethods.asp
It looks like you want a very detailed answer so you can find it yourself:
Google it and read thoroughly the pages (wikipedia for example)
Read http://www.w3.org/TR/XMLHttpRequest/
Inspect the packets between your browser and the server
I'm been reading up on Ajax and would like to see from the stackoverflow community if I'm understanding everything correctly.
So the normal client server interaction is a user pulls up a web browser types in a url and a HTTP request is sent to the server requesting the page and resources( css, pics ) from the web server. The web server responds to the client via HTTP the page/resources requested and the browser renders the html/JavaScript for the user to view the page.
1) So would it be safe to say that XMLHttpRequest( XHR ) object is doing the same process as the browser except your not requesting html from the server, your requesting text in some type of format?
2) Is it true that a XHR object is much like a regular object that can be manipulated by the program creating the object( like a normal object ), but also sends and receives data with another program( web server ) via HTTP?
3) So in my mind when a XHR is created it is loaded into memory and we setup some of the objects arguments when we do the request.open(“GET”, url, true). Once we do a request.send(null) the object basically attempts to “GET” the url via HTTP and once we get the data back from the server it is put in the responseText argument. Am I understanding this correctly?
4) Also synchronous vs asynchronous. When I think of synchronous I think of steps having to be followed in order. For example, I push a button, data gets sent to server, and I have to wait for data to come back before I can do anything else. With asynchronous connections I would push button, data gets sent to server, I do what ever I want while data gets sent back. Is this a good analogy?
1) Nope. The XMLHttpRequest object does exactly what its name implies -- it initiates an HTTP request. This request can be in XML, or HTML, or PHP. At the end of the day, the browser doesn't care, because in an AJAX request, it doesn't parse the request -- you have to do it yourself. So it doesn't automatically render the HTML from an AJAX request.
2) I'm not sure about manipulation (the XHR object may be immutable) but possibly. Would you ever need to extend it or manipulate it?
Yes, you can change properties of the object and so on. I apologize. I didn't understand you at first :)
3) Yep.
4) That's a great analogy. It's exactly what happens. Another analogy is a 4 lane highway is to asynchronous as a one-way street is to synchronous. If one car breaks down on the 4 lane highway, the rest can keep moving at their normal speed -- but if one breaks down on the one-way road, everything freezes. :)
Here I leave you a good graphic to see clearly the behavior differences between the synchronous and asynchronous application models:
(source: adaptivepath.com)
It would appear that you have a job grasp of how AJAX works. I can't see much to disagree with in your summary of the plumbing of an AJAX application.
I would say however that with the XMLHttpRequest object you aren't restricted to GET. You can also use POST and other HTTP verbs.
With async calls you register a callback function, the XMLHttpRequest object calls your method when the async request completes.
Seems ok to me.
Your first point though is not entirely correct, you can request html from the server using ajax is doesn't have to text, json or xml like most examples show.