I am trying to intercept all web requests using by Puppeteer-Sharp but it is not working properly if the request sent by IFrame which is located on the page. For instance, After navigated this link, I clicked the video link since the video is in the iframe(maybe this is not the cause, this is only my hypothesis), the new web requests sent by IFrame did not intercept but the others were intercepted. When I checked it on the Chrome Developer Tools I was able to see what I am looking for and also more requests.
By the way, I set Request Interception as true as below:
await page.SetRequestInterceptionAsync(true);
and I registered for the PageRequest event as below:
page.Request += Page_Request
Is there any other setting or missing setup?
Related
my client side react app is running on http://localhost:3000 and my node js server is running on http://localhost:8080. When client url is loaded, it sends GET /auth/user 304 0.494 ms - - fetch ajax request to load user(on react componentDidMount function). Problem is, when typing 'l' on Safari browser and url is autofilled with 'http://localhost:3000', it is confirmed that my server get the same request as GET /auth/user, before I even press enter key and before the client page is loaded. In Chrome it doesn't. Why Safari browser sends ajax request when user didn't visit the page and just typed part of its url? Is it a designed behavior?
As a result of tracking the reason for 6 hours. I figured out Safari implements cached ajax request differently from other web browsers. When Safari has client url data which has records of requesting ajax to external api, Safari sends the same ajax request just before user visits the client url page(when url is being typed and auto-suggested) to check if the response is 200(different) or 304(same). If the response is 304(same) and client page is loaded actually, Safari doesn't send ajax request again. This can be very annoying in the user login process, because the user data is loaded before actual authentication process is complete(user data response is 304), so client app remains unauthenticated when browser is authenticated. The solution I landed was adding an extra query parameter when fetching user data( '${root}/auth/user?' + 'nocache= new Date.getTime()' ) to prevent Caching AJAX in Safari browser. Hope it helps someone who faces the same problem.
I want to get the post request data of a website. Is there any tool or addon for this? I can't see in the browser firebug as the page refreshes when the browser sends a request.
Install Httpfox.
You can see all the incoming and outgoing http traffic with it
Say I have a web page, and it has a websocket chat running on it. Now, my plan is, when the user clicks on any of the links of the page, the page is not refreshed. Instead, I send the request to the websocket (the same one on which the chat is running), and it returns the new page.
So, is this a good idea? Or should I go for Ajax?
Ajax would be easier. You don't need branching inside the chat websocket listener this way, just request the needed page and put the response into the page body.
I'm using a website, abc.com, that is hosting an iframe of a page on 123.com.
The page inside the iframe is doing an AJAX request to another page on 123.com, but we're seeing that the request is getting cancelled.
Unless I'm wrong — and I haven't found any official information on the internet about this — the call should work fine as it is not a cross-domain request.
Would the fact that the parent frame is on a different domain really hinder the iframe from doing AJAX requests to its own server?
The IFRAME should be able to make an ajax request to its own originating site (same source URL). However, make sure the REQUEST event is FIRED from the IFRAME, not the parent.
My first guess would be you are loading the IFRAME and then addressing it (firing an event) via the parent (JS) to get it to do/get/set something which triggers an ajax call. In short, this is the mostly likely reason the IFRAME domain to same domain request is getting cancelled as it is still recognized by the browser as originating from outside the target domain code.
The REQUEST event needs to be organically generated from the user clicking on something in the IFRAME or from code in the IFRAME itself firing the event.
In other words: just because the IFRAME may have some ability to fire events/ajax in its JS/code to/from itself, it would normally still not be allowed to have the parent reference that ajax/JS directly via JS/code. The IFRAME has to already be coded to do it based on its load parameters (URL values, perhaps) or the user has to physically click/take action on something to create a user generated event on that domain.
Of course, this is going to vary a bit by browser and version on what you might be able coax in terms interactivity between the parent and iframe. But a strict, up-to-date browser will try to keep you from faking insecure interaction on the iFrame via js.
To get a better answer, you would need to provide more detail on exactly what you are doing/getting.
Is it possible to write and create a JavaScript Ajax request witch cannot be catched by the Firebug plugin in Firefox?
I'm asking this because I can see on Facebook that there are no Ajax request going on, but still when I sent a message from another Account, the message box on the top will add the "1 unread message" indicator... How's even this possible to achive?
Thanks.
Firebug logs "standard" AJAX requests to the Console panel; these are requests initiated using ActiveX/XHR.
Other types of requests are happening, though - CSS loading, images, javascript, etc. These requests are logged in Firebug's Net panel. Note also that requests logged in Console also appear in Net.
JSONP is a cross-domain method of AJAX in which a <script> tag is added to the page. When the request completes, the loaded contents of the script tag are parsed as JSON. The reason this works is that you are "tricking" your browser into treating the request as a request for a javascript resource rather than an AJAX request, thus skirting cross-browser security restrictions.
Putting this all together, JSONP requests (as well as all other types of requests, listed here as well as all <iframe> requests) are logged on the Net panel rather than in the Console panel. This isn't a bug or a problem; understanding the way JSONP works it is logical that the request would only appear in Net.
When using jsonp as your data type your calls do not show up in Firebug.