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.
Related
I'm working on an application that uses the Django Rest Framework. For testing purposes, we occasionally use the default Django Rest Framework page for debugging or testing purposes.
Another developer recently discovered, that with one of our endpoints (that only has a POST method on it) immediately redirects without showing the last posted content of the POST call. The redirect results in an HTTP 405 (method not allowed). This behaviour is unlike most of our other endpoints - even those that only have a POST option. when they are posted to, they show the content of the POST call, as well as the text box that allows another POST.
In digging into this, I discovered that this particular endpoint was returning a response in the form of an HttpResponse object, rather than a Response object. It was also specifying the application/json content-type for the HttpResponse object.
In playing around with this, I discovered that if I switch it to use a Response object it doesn't cause the Django Rest Framework page to redirect, and does show the response on the page. However, if I specify the content_type on the Response object, the Django Rest Framework page starts redirecting again, without showing the last posted content.
In any of these situations, it is still possible to see the response by resorting to using the Chrome Developer tools and enabling "Preserve log", so that the network call history isn't cleared with the redirect, however this is less than ideal.
In changing it to use the Response instead of HttpResponse objects, it also broke one of our unit tests, as the unit test wasn't specifying the content-type header of application/json, but was expecting a JSON response. There may be other places that are also calling it without specifying the content-type header, so ideally I would like to be able to specify a content-type on the response, but still have the Django Rest Framework page show the last POSTed content.
My questions are thus:
What causes the default Django Rest Framework page to display the last posted content (as opposed to redirecting)?
Why does specifying a content-type on the Response cause the Django Rest Framework page to not display the last posted content?
I have build a CMS where pages are build with elements. Each element has fields etc. When editing a page all elements (with their corresponding fields) are put in an accordion. When clicked on a accordion title, it opens the element (with fields and values). Data is retrieved using Ajax. When the user edits the fields, he clicks on save, which triggers another Ajax call.
The thing me and clients are noticing, is that if you work fast (like opening one element, whoops wrong one, lemme open another etc), the user gets logged out. An error 401 is sent saying 'Unauthorized'
At first thought this had to do with the CSRF tokens. Sent it as a _token field or in the headers with the Ajax calls etc. When this was not working I decided to make a token exception for all Ajax calls, but still the same problems.
It looks like, when one ajax request is still being processed and I call another, I get logged out.
So my question is, what to do about this? As it's very annoying for the 'fast' users among us.
After reading this article: https://github.com/laravel/framework/issues/7549 I have set the session storage to database. Now the errors of 'unauthorized' do not happen with the multiple ajax request we do in our CMS.
I have an ASP.NET MVC website with drop down lists and when the user selects an option in the first drop down list, the other drop down lists are populated using an AJAX call. Based on the logs, crawlers try to access these AJAX methods as normal gets and because of that my app logs errors. I made those AJAX methods as not crawlable, meaning that I return a 404 when the request is not an AJAX call. Is this the best way to do it?
On the other hand, I have a page that has multiple steps, meaning that the user fills a form and then goes to a second step. Every time the user fills a form I do a POST AJAX request and saves the input data. How should I manage this situation?
Add URLs you don't want crawled to robots.txt.
If you offer a link in GET form crawlers will try to crawl it. Returning a 404 is not technically correct - it does work to deter crawlers from indexing the page though!
Consider returning a 500 Internal Server Error or 501 Not Implemented.
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
We are using Primefaces 2.x and Mojarra. We are trying to handle one particular case where you log into our site and then delete all of the cookies. Then click on a menu option. What we would like to have happen is for the user to be redirected to our login screen. The problem is that we are not using the "url" attribute, so Primefaces does a partial-page ajax call. Which returns an empty response.
At this point, without a Session Id there is no session. So, on the server we are in the midst of an Ajax call without a session. If I try and do a sendRedirect it sends a 302 to the browser, but either Primefaces or the browser is ignoring it because it is part of an Ajax call.
So, what I would like to do is to put a listener on the Ajax response and look for a 302 or a change in the location. However, I can't find a way to use the jsf.ajax.addOnEvent. It seems that Primefaces is not using the standard JSF Ajax calls. I looked at the AjaxStatus but all it gives me is events, no DATA and no access to the data.
I thought I could look for the JSESSIONID cookie, which the user has deleted, but when I use Javascript to print the cookies, the session id isn't printed.
So, I don't seem to be able to do a response.sendRedirect in a Session Filter because I am in the midst of an Ajax call. And I can't detect on the client that I need to redirect the user, which I could do if I knew it was required. And I can't seem to get any info out of Primefaces Ajax response.
By menu you mean the p:menuItem component, right? Assuming you're using the action attribute to call a method in your managed, try using the attribute ajax="false". I use that and it works well for me.