We are exploring the use of a PHP framework, Slim, and are interested in the ability to log, debug, and analyze all sever-side HTTP requests that framework views are making. We would like to see the results of those requests client-side.
For example. We have a route /foo. The view for route /foo makes three API calls to an API on the server, interprets those results, and returns a response. We would like to see the request parameters, header information, and response from those three server-side HTTP requests from the comfort of our browser. We've seen client-side debugging tools like the PHP Debug Bar, which looks like good scaffolding for displaying information from the server-side HTTP requests, but aren't clear how it would record and/or know of those server-side requests.
Previously, all of our API calls were made from the client and it was trivial to observe and debug these in browser development tools.
We've stumbled across standards such as HTTP Archive logs (HARs) that were made for capturing HTTP requests/response transactions in JSON form; is there way to record and bubble this up? More specifically, are there debugging tools in place for PHP frameworks that might have all this wrapped up in a tidy bow?
This would be for debugging only, as obviously it would make each route render much heavier for returning all that information around those server-side HTTP requests.
Any thoughts or suggestions would be most welcome!
Related
I am working in a complex Webframework with lots of Javascript in the Frontend and lots of PHP in the backend. Since I’m new to it, finding out the workflow is quite a hassle. Is there a way to log the complete sequence of function calls (in PHP, JS or both) from the moment a request is sent until the response is executed (or the JS after the request has been sent is executed?) That would be really helpfull.
There's no perfect solution here but you will probably have to just use browser debugging tools like Firefox's Firebug or Chrome's debugger . Using these tools you can see JavaScript errors, AJAX requests, PHP (server) responses, individual page file loads etc etc.
All I can think of would be using Chrome developer tools, network tab in order to see the sequence of events. Or maybe even better, the HTTPFox plugin in firefox.
That will help you to find out the execution order of JS calls and which PHP files are accessed via AJAX.
What's happening on server side isn't easy to follow, but you could debug your code using XDebug.
I have been looking at writing my own server using kqueue. I can do this with really no problems as long as I can control what kind of client will be accessing our system. Realistically, however, I would need to accept from standard web clients, including AJAX. I have been looking for examples of programs that use XMLHTTPRequest to connect to a custom server written in C. I have found nothing.
Can you help me?
Bruce
Ajax just means "Making an HTTP request using JavaScript". It isn't a client.
As far as the server is concerned, there is no difference between an Ajax request and any other HTTP request.
(Some libraries add an experimental HTTP header to state that the request was trigged by Ajax, but when you care about that on the server, it is almost always at the application level rather than the server level (i.e. your server side script not your HTTPD)).
I've used a bit of AJAX with PHP for things like submitting forms and I've recently started looking into websockets. I followed this tutorial to understand the basics. From what I gather, websockets keep the connection open whereas AJAX opens and closes a request.
My question is do websockets provide any advantage over AJAX if you're just submitting forms or simple tasks like auto_complete (which there's a jQuery plugin for anyway)? Maybe the tutorial isn't the greatest, but it seems like there's a heck of a lot more code involved to get websockets to work(at least with PHP) than just a simple AJAX call (or using jQuery which bundles it). I've read in a few places that it's a bit quicker, but if I'm working on something that isn't receiving tons of requests, will it really make a difference? Correct me if I'm wrong, but not all browsers support websockets either, right?
Websockets have two advantages.
they have much less overhead, which results in a better network performance
they allow the server to send data which the client hasn't explicitely requested.
The second one is the most important advantage.
In AJAX, everything the server sends must be the response to a previous request by the client, and every request can only be answered once. But in many applications, especially multi-user applications, events happen on the server and these events must be pushed to the clients immediately. There are workarounds for that in AJAX, like delaying the answer to a request until there is something to report (long-polling), but these are quite dirty. That's why there are Websockets. With a websocket connection, the server can send messages to the clients when it wants and as often as it wants, without having to wait for a request from the client.
But unfortunately WebSockets also have disadvantages:
They aren't as well-supported by web development frameworks (yet!)
Not all web browsers support it (but most desktop browsers already do)
Many proxies and reverse-proxies can't relay websocket traffic (yet!)
Actually, AJAX and websockets are two different categories. AJAX is a concept, a technique. With AJAX you can perform (as the acronym stands for) asynchronous requests, so the browser doesn't need to reload/refresh the whole page. This is good for different things, e.g. checking form input.
Websockets are a protocol, technically quite the same as http, unless the connection will not be closed after transmition. This is good for things, where the webserver may need to contact the client (http can't do that), like a push service fore example (chat or mail client where you want to update the user interface even when the user does not refresh the page, or games). And it kills the http overhead as the whole thing has only to be done once in the beginning.
So, their for different purposes, even if they overlap. For your auto-completion I think it won't make a real difference in performance. And it even is a action/reaction thing, so the user types or submits (whatever) what can cause a request and the server responds.
Websockets is a powerful technology and could certainly cater for the limited use cases you;ve mentioned but there can be compatibility problems with older browsers and network intermediaries. In fact some folks even recommend having an HTTP fallback in case Websockets isn't supported.
Unless you have requirements that necessitate websockets, such as full duplex bi-directional communications for example, you might be better off using existing AJAX based solutions.
If you have requirements to push notifications to your user interface, Websockets can be a good idea, but if you are literally looking for form submission and auto-complete, then these problems have already been solved using Ajax.
Disclaimer: May be a insane question but I have suffered a lot so came here.
I am working on a legacy application which uses JS + PHP + Web services (Written in spring).
Flow of the application :
Whenever any web service is called from JS it is redirected to one php file. The php file authenticates the user(using one web service) and then forwards the request to actual web service.
How can I debug this application ? I have debugged JS using Firebug and servr side code using Eclipse but never debugged such a application.
~Ajinkya.
I think there are a variety of things that need to be done, and I must say this question is sufficiently general as to not have a straight answer so I will do my best. As xdazz mentioned, var_dump (and die) are necessary from the PHP standpoint.
Whenever anything is returned to JS console.log it. In addition, ensure XHTTP requests are turned on for Firebug or alternatively view the output of each request in the Chrome Network tab.
With a combination of console.log, var_dump, and die, you can trace non-functioning parts of the application repeatedly step by step until you come across the bug.
Alternatively, and in the long run you ought to be doing this anyway, build error handling code into all the PHP code that is only activated when a debug flag is set to true. This way you can get detailed error messages and then when you deploy, you can turn them off to avoid compromising security.
If you are needing to inspect the entire lifecycle of a Web service request in your scenario you will need to combine a several techniques. Considering the fact that the scope of your scenario spans from client to server you will need to decide with what you will persist the information you need to inspect.
Personally, I would choose the path of least resistance which in my case would probably be cookies. With that being said you should be able chronologically log the necessary information via JavaScript and PHP, both before, during and after the request and even redirect has occurred.
This strategy would then allow for the information logged with cookies to then be dumped or analyzed via JavaScript, WebKit inspector or Firebug. Again, this is probably how I would handle such a scenario. Lastly, you can apply different storage strategies to this technique such as using a session or database for persistence.
Note: You can use something like WebKit Inspector, and possibly Firebug, to analyze data transmitted and received for GET, POST and even WebSocket requests.
what is the equivalent of ASP.NET HttpModules in PHP?
If there are any how can I include them for that specific application (not globally) in other words what is the equivalent of web.config
Example : I need to log the request and the headers, if the server is returning a HTTP 500 error irrespective of the code which is run.
In ASP.NET, I would have a HTTP Module in which I can grab the response code and other details, before sending to the client. I can also handle Begin Request.
I need something similar in PHP
Unfortunately PHP is more like ASP in the sense that the "application" is a loose concept, the files are not tightly related, so anything you do would likely have to be at the web server level
Assuming you are on a linux/apache server. One approach would be to use .htaccess, these can be modified at the directory (ie application level) and have sever powerful features.
One example is for url re-writing:
http://roshanbh.com.np/2008/02/hide-php-url-rewriting-htaccess.html
Official Apache Docs: http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
You can look the ModSecurity for Apache: http://www.modsecurity.org/
It will allow you to log full POST and headers data depending on rules you define.
ModSecurity configuration is very powerful but very complex too.
HTTP Traffic Logging
Web servers are typically
well-equipped to log traffic in a form
useful for marketing analyses, but
fall short logging traffic to web
applications. In particular, most are
not capable of logging the request
bodies. Your adversaries know this,
and that is why most attacks are now
carried out via POST requests,
rendering your systems blind.
ModSecurity makes full HTTP
transaction logging possible, allowing
complete requests and responses to be
logged. Its logging facilities also
allow fine-grained decisions to be
made about exactly what is logged and
when, ensuring only the relevant data
is recorded. As some of the request
and/or response may contain sensitive
data in certain fields, ModSecurity
can be configured to mask these fields
before they are written to the audit
log.