Here is my situation:
I am using Symfony2 as a middle layer here, when web client ask for a webpage to Symfony2(the layer), the layer is going to request single/multiple data/image to another backend remote resource server by http, combine them and return to web client.
And I also wish to have caching in order to reduce requests to the backend server.
I found that the ESI has similar manner, however, could I include another server resource in Symfony2?
Is there any proper way to implement this? Thank you!
It depends whether you have Varnish installed in front of Symfony2 or not.
To be clear: Symfony2 ESI Proxy won't call any external resources, and will only call your app's controllers.
Varnish is able to handle the ESI from any sources.
Related
The logic behind varnish is that it never touches your ruby/php code base and served directly by the cache. What if I have an ecommerce site and for each category page I want to log a particular page viewed by user/ip address X at what time, I have put this logging code in my php code. However when I run the app with Varnish then I lost all of this ability. I am pretty new to gateway proxy cache, can anyone enlighten me?
The easiest most efficient way to solve this is to create an ajax request that does just the logging part. That way you can still cache your whole page whereas you disable cache for the ajax request to enable it to log all users. The IP you would forward from varnish to the ajax request (with X-Forwarded-For), the URL you easily get with javascript and include in the ajax call (browser referral headers are not reliable).
A rather simple thing is to write a script to parse varnish logs, and retrieve pages of interests, ips and other interesting informations. It can be run once a day or more frequently, depends on your needs.
By using ajax request as in #Clarence response you risk to do not include the visitors with javascript not activated (but you can have your stats in real time)
You can add some logic to Varnish to forward IP address, so you could have complete webserver logs of client IP & requested URL.
This example is for apache: Varnish Client IP not logging in Apache Logs
[Edit] The above suggestion only works for cache misses. Client side JS recommended.
You could also consider using javascript to poll servers with information, such as Google Analytics. http://www.google.com/analytics/
I am using NGINX as my web server for html/js/css files and my web app UI. It is a single page app that uses AJAX requests to a back end JEtty server. Previously I deployed everything in Jetty and ajax calls worked fine. In separating the back end from the web UI tier, I am now trying to figure out how to configure NGINX to allow AJAX requests to pass through to Jetty. But, I ALSO want to prevent someone from watching network traffic and seeing the ajax calls my app makes, then scripting those themselves. To do this, I believe if I can configure nginx to ADD a custom header to the requests as they pass through (is this even possible?) I could then only accept requests with those headers at my Jetty API level.
If that is possible, is it the right way to handle this so that outsiders can't get in to my back end API? Is there a way they could figure out that my nginx server is adding a header short of breaking in to my server and figuring out the configuration?
If your application calls your api via Ajax on the client there's nothing you can do to stop someone from calling it directly (assuming they otherwise have access to the page). At the end of the day, an Ajax request is just a request made from the client in JS. Now, there are lots of stupid ways to make it more difficult, but, if anyone really wants to call your api directly, they can.
If you're just talking about only allowing access through nginx (or specifically your /api location block), just bind jetty to localhost only.
Problem:
A part of a web application contains another web application from another domain.
Both web applications make AJAX requests to the domains they originated from which poses problems because of the same origin policy for AJAX requests.
Solution:
One way to achieve this is to wrap the contained web application in an iFrame. The AJAX requests in it go to the the same domain of the iFrame - which is different from the parent application.
This sounds fine to me, but since iFrames ae unfashionable, what other / better way is there to do this?
Are you not able to have both applications send an AJAX request to your domain, and have your server side perform the call to a foreign domain, and then relay the result it receives back to the requesting client side App. Your server in essence becomes a proxy for the AJAX request?
What do you men unfashionable? If you like to hind you can apply height to 0 and display none.
I have been trying to get this resolved, without any success.
I have a webapp residing on my domain, say www.myDomain.com. I need to call a service which is present on another domain, say www.anotherDomain.com/service.do?
I'm using SproutCore's SC.Request.getUrl(www.anotherDomain.com/service.do?) to call that service.
I get an error that says, Origin www.myDomain.com is not allowed by access-control-allow-origin.
When I was in dev stages, and using sc-server, the issue was resolved using proxies. Now that I have deployed the app to an actual server, I replaced all the lines where I had set up the proxy with the actual domain name. I have started getting that error again.
The problem is that I CANNOT MAKE ANY CHANGES to the server on the other domain. All the posts that I have come across state that the other server on the other domain ought to provide access-control-allow-origin header and that it ought to support the OPTIONS verb.
My question is, is it possible for me to connect to that service using SproutCore's SC.Request.getUrl() method?
Additionally, the other posts that I have read mentioned that a simple GET request ought not to be preflighted. Why then are my requests going as OPTION instead of GET?
Thanks a ton in advance! :D
This is not a Sproutcore issue; it's a javascript Same Origin Policy issue.
If you can't modify the production server, you have no option but to develop your own proxy server, and have your proxy hit the real service.
This is effectively replacing sc-server in your production environment.
All this server would do is take the incoming request and pass it along to www.anotherDomain.com/?service.do.
You would need to make sure you passed all parameters, cookies, headers, the http verb, etc....
This is far from ideal, because now errors can occur in more places. Did the real service fail? Did the proxy fail? etc.
If you could modify the other domain, you could
1) deploy your SC app there.
2) put in the CORS headers so you could make cross domain requests
Is it possible to directly access third party web services using Ajax? Mostly I've seen that the website I'm visiting handles it on its server and then transfers the processed/unprocessed data to client browser. Is this always the case?
(yes, almost always)
Typically, when you're trying to accomplish accessing third party web services a proxy server is used to access those services. You can't reach external third party web services because they exist on separate domains and you run into the "Same Origin Policy"
Now.... there are methods for doing cross-domain ajax, but the service you are accessing must support it (there are restrictions on what kinds of data can be returned and how the requests are formatted due to the way cross domain ajax works)
A simple way to do this is indeed by using some sort of server-side proxy for your request. It works like this. You do the Ajax request to your own domain, lets say proxy.php. proxy.php handles your request, forwards it to the 3rd party service and returns te results. This way you don't get the cross-domain errors. You can find multiple examples of these simple proxy's by using the magic Google.