Yii2 comes with a great debug module.
Sadly, I can not view Ajax request. It seems that only standard request show up in the log.
I would expect that under Requests/Last 10, I could go back to an Ajax POST request.
Is there a way to do that?
=====
Update: The accepted answer is correct. But, it turned out that my problem was elsewhere. I was running the site from a testscript with url: test.php/controller/action
In that case, Yii2 ActiveForm includes an action controller/action in the form. It omits the entry-script. I wonder if this is a bug? Or is this intended behavior?
Of course, my debug modules is only attached via the test entry-script, and therefore missed recording the ajax POST request.
Click on the icon with label "Yii Debugger" at the left side of the debug toolbar.
debug/default/index - here you can view latest requests. Filter Ajax only if needed.
Defailed info about request is available after clicking on the tag.
Related
The question is probably easily misunderstood, so I'll go into more detail:
I am trying to automate a task in a certain (very outdated) browser-based idle game that is written in PHP in order to polish my portfolio with a little more variated projects.
I used DevTools to reverse most of the requests and wrote a small C# Request wrapper to test them. I can get most of the actions I want to work, using the respective ajax get requests and the correct cookies/headers - not really part of the problem.
Example:
Attacking an enemy:
https://somebrowsergame.com/game/ajax.php?mod=location&submod=attack&location=3&stage=2&premium=0&sh=****mysessionhash****
Making a GET request to this URI with the correct headers and cookies, I can perform the in-game action programmatically and successfully from my C# console application and see that the fight has taken place when visiting the site in the browser.
The problem:
When monitoring all requests after clicking the "attack" button, via DevTools, even with preserve logs enabled, I don't see any redirects or way of determining how my browser gets told where to navigate to.
Findings
I found out that the button calls a javascript function attack() in its onClick event and tried debugging the javascript in DevTools in order to find out where somethign happens (such as setting document.href or smth), but when Debugging I ran into a seemingly infinite loop of setInterval handler and setTimeout handler in the call stack.
I also cleared the Network tab after the onClick event (and after the ajax request which I could find during Debugging) but the only request/response I got was the document GET request for the final page, no request telling my browser which site to navigate to.
Monitoring requests
The request made to initiate the action (via button click on website or ajax GET request as outlined above)
The document response / site navigated to
What I want to know is how my browser got told which site to navigate too, as the request URI for the document request (getting the html of the target page) has a parameter generated on the server side (logId)
I have also used "All" request types in DevTools, as well as negative filters when monitoring requests but never was I able to see how my browser knows which page to navigate to. I tried with source breakpoints at "beforeunload", tried inspecting the javascript source connected to the onclick event of the button (which didnt give me anything, as the js is minified and barely readable - i am not even sure if the navigation is done via window.target.href) and googled this question in all possible wordings which lead me nowhere
I am not too versed in web development, but I am sure my browser has to be told where to navigate to in some fashion after clicking that button?
community,
i have a symfony project (3.1.10) and use ajax requests (jquery.ajax) to load data. If the request fails, the debugger toolbar shows the error but creates no profiler entry, there is only a n/a in the profile column. So i have no chance to get the reason for the failing. I remember in symfony 2.7 there was a profiler entry for failed ajax requests. Can someone help me?
Make sure that the URL of your AJAX request actually uses the app_dev.php front controller. Otherwise no debug data is recorded for the profiler to display.
Seeing the same. But you know you always can open /_profiler/ page on your instance, find your ajax call and find out what happened.
Can I use Firebug to inspect a post request sent by a webpage to a server and if so how?
I am refering inspecting a regular POST made using a form, but would also be interested in knowing how to inspect posts using javascript.
Thanks
Of course you can do that. The Net panel allows you to expand every request related to a website. For a POST done via AJAX you can set the XHR filter to see only those requests.
If you expand a request by clicking on it, you'll get all the information related to it.
Sebastian
My web app runs under Tomcat, it uses AJAX requests very intensively, and during the development process I have to redeploy the web app intensively too. After the redeployment I usually simply refresh the page knowing that the user session is dropped, but I always get to the scenario described below:
Go to some page, a really big page with many JS-scripts included, that actually makes those intensive AJAX requests.
Stop Tomcat or redeploy the web app.
Refresh the page.
Enter the credentials in the sign-in form to authenticate.
Suddenly get the last AJAX request response in the browser window and the AJAX request URL in the URL bar.
Wow... It looks strange for me that AJAX request URLs appear in the URL bar along with their response in the web page display area. This actually happens to Firefox and Chrome (haven't tested it in other browsers). Unfortunately, I cannot reproduce the same behavior in a simple page written from scratch. Frankly speaking, I don't really understand what happens to such requests and why do browsers "think" if AJAX requests/responses are entered in URL bar by user...
Your possible explanations or hints for such a strange behavior are very and very appreciated. Thanks!
(Perhaps it can help: All AJAX requests are performed with jQuery 1.4.2)
I'm very sorry, as I understood later, the question is not complete, because there was another pitfall I didn't mention, so no one couldn't answer the question in principle. The reason of the bug was hiding in the... <body onunload="..."> tag definition. That was quite unexpected, but that code contained some AJAX request that must be invoked when a user leaves the page. I only realized that the authenicating module (FORM, j_security_check) returned a response (HTTP 302) containing the Location header - so that was the reason why browsers did redirects.
The exact scenario was like that:
Open the page containing <body onunload="some_ajax_here">.
Log out the app using another tab so you could stay at the same page.
Refresh the page so some ajax could be invoked - this AJAX request is not now allowed because it's a secured part of the application (you get the forwarded content of the login page).
Enter the credentials and now oops you get to the result of some ajax directly in the browser window.
As the quick fix, and I hope the final one, I added another request following that AJAX request:
$.ajax({
async: true,
method: "GET",
url: document.location.pathname + document.location.search
});
So the HTML page script simply makes self-page request the last one - j_security_check returns the Location referring the last used HTML page, and the redirect works fine. Perhaps my explanation is not clear and may be not complete or even full of mistakes, but it looks like that in general. I'm very sorry once again, and thank you #ChristopherSchultz!
1) I saw an interview question on this, and I'm assuming it's something to do with form submission and avoiding double submissions. Can someone confirm this?
2) Assuming this assumption is correct, can this be done with Ajax? If so is there a link someone can point me to?
(I'm assuming you'd generate some sort of random number and include it in the form as a hidden field, then ensure that number hadn't been submitted before for the session).
Redirect-after-post is a technique to avoid problems with the user refreshing or using the back button to get back to a posted form. In short, instead of providing a response page to an HTTP post, which will trigger another post if its reloaded, you issue a 303 redirect (or a 302, to support ancient browsers by taking advantage of a bug that is as old as the web). This causes the browser to issue a second HTTP request - a get this time - and if the response page to that is reloaded there shouldn't be any problems. Just make sure that all the changes are made by the post handler and the page you redirect to has no side effects.
If you post using XMLHttpRequest then the redirect will be followed; unless you specifically support it using the hash part of the location or the new HTML5 history methods then the back button and reload aren't going to trigger an AJAX post again.