Ajax Status/Response Data from Primefaces - ajax

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.

Related

Scraping a website made with ICEfaces (session expired on consecutive ajax POST requests)

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.

Where do AJAX requests in an MVC application enter the server side code initially?

To keep it simple I have a feedback form on my website. Whether or not the following is best practice is moot as I'm interested in the way this works. The customer can fill out their name, email address and reason for feedback on the form. This is then posted via AJAX to a server side function called SendFeedback. I am using .NET MVC4 and the SendFeedback method simply returns a true or false string. However I was testing out sending scripts through it to check out the security of the form and noticed that when I attempted to send through HTML tags or javascript that the SendFeedback method wasn't being invoked at all and instead my custom error page was being sent back to the client side AJAX response (if I sent though standard text, the SendFeedback method was being invoked as expected). Where is the first place that AJAX data is sent before it is passed into the server side method I am calling from the client? Is there any way to set a breakpoint here so I can examine what is going on?
This is part of an ASP.NET feature called request validaiton which is turned on by default. And which executes in ASP.NET handler before your code. If you desire, this feature can be turned off in web.config, but I would strongly advise against it.
More information on request validation can be found in MSDN.

Grails 2 - Too many Ajax calls will invalidate user sesssion

*update: sorry, i didn't give a context. I'm using Grails 2.1.2 with the spring security plugin installed. Js lib -> jQuery (latest)
I have a page that submits lots of synchronous ajax calls (not my design, sorry). After the 25th call i see from firebug that i start getting http 302 status, then the handler for ajax calls when there's no user session is called (loing/authAjax in my case). My particular handler sends an http 401. In any case why is the session expiring? This happens only when i submit tons of synchronous ajax calls. Is there any limit to the number of ajax calls? Is it documented anywhere? Making async calls is not an option in this case because these ajax calls make db updates on the same table and that would result in a hibernate lock exception.
I'm not asking for a fix, i know how to fix this (by doing one single ajax call). What i'm asking is why the session is being invalidated? Any ideas?
Did you try to set the cache setting to false in your calls with jQuery ?
302 means you're getting data from the browser cache instead of the server.
Hope this help....

does post-redirect-get need to happen for an ajax request?

is there any reason to use the post-redirect-get (prg) for a request that you know will only happen via an ajax request?
in this scenario, you might have a request that is sent (either via ajax or direct), and we're assuming on the back-end we can distinguish which is which. In the case where the direct request is handled using prg, is there any reason to also handle the ajax request with a prg too?
or can an ajax post just be responded to directly?
For something that only uses AJAX, I can't see a reason to use prg. Since it is not a user controlled action with the possibility of duplication, the only way the AJAX call would be duplicated is if the original page was refreshed before the action finished, and since prg has that same one flaw, you may as well use the direct approach.

difference between ajax and form submit

I just want to know what is the difference between sending parameter with ajax(post/get) to a servlet and sending them with "submit" .
Thanks for your help.
A standard form submit sends a new HTTP request (POST or GET) and loads the new page in the browser. In Ajax, the data is sent to the server (POST or GET) in the background, without affecting the page at all, and the response is then received by javascript in the background, again without affecting the page at all.
(The javascript can, of course, then use the data received from the server to update some of the page content.)
Ajax is generally useful where only a small section of the page content will change.
At the simplest, with ajax, you don't witness page refresh while submitting form data. And if you don't use it eg you use submit buttons, you witness page refresh. Both submit the data.
Server side handling of both are exactly the same. The server is not concerned about how the post request is made.
The difference is in how the browser (client side) responds to both the actions. The browser usually decides to make a request for an entire page if it is a form submit; otherwise, it just updates a part of the page.
From the servlet's point of view there is no difference. For the client, a submit will load a new page, while an Ajax request will parse the response with javascript code and act accordingly.
The form submit will reload the page that you are working on client side.,while in ajax call the call was made to server will not reload your client side page

Resources