My question is bit similar to this one
However, I'm looking to do this programmatically... for security reasons my proxy must operate without any prior configuration in the browser (proxy settings ..).
in other words , force all http request (browsers )to pass by my proxy, without any configuration, because it's easiest to delete the proxy settings by the user...
there is any tricks to do that ?
If this is a windows domain use group policy to manage proxy settings.
If you are trying to do this subversively you may way to read this
http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/
Gotta love WPAD!
I hope it helps,
dc
Related
This is my scenario:
So,
Requests via encrypted HTTPS go to Apache like: https://server1/MyPerlApp
If the user is not logged in, they get a redirect to some login page (in the server1), and Apache doesn't proxy the request to Server2
When the user logged in - IS authenticated - then Apache forwards all requests that are coming to https://server1/MyPerlApp to http://server2:5000
Question1: Is this possible? (Asking, because I don't know Apache enough deeply, and this is not an simple:
ProxyPass /MyPerlApp http://server2:5000/
because I need need authenticate the user at server1 and set ProxyPass Only if authenticated.
Since Apache is quite flexible I assume the answer is yes for the above (but confirmation and details is very welcomed) - so here are my main specific questions:
How will my Plack application know what user is authenticated at the Apache level (i.e. on the 1st server)?
what is an easy way to deliver some of the user info to the perl app on the server2? e.g. with Apache's mod_rewrite what appends an user=username parameter to each query,
can Apache can set some HTTP headers that my perl app should read?
is there an easy and recommenced way?
I'm looking for how to avoid authentication routines in my starman/perl app, maily because:
the user need to log into server1 anyway (for other tasks in his workflow)
if he is already logged in, authentication in my app is not needed (avoid unnecessary double login)
but I still need to know which users are logged in (via Apache at server1)
There is already similar questions, but:
https://stackoverflow.com/q/12561830/734304 (no answer)
https://stackoverflow.com/q/11907797/734304 (no answer)
Apache reverse proxy with basic authentication (similar, but the backend is in the same server and same apache)
[I think you asked four questions here. Some of them overlap. I will try to answer as many as I can, then edit your question to make it a bit clearer. It might be helpful to post your current Apache httpd.conf so people can see how you are handling access and authentication currently. That way you might get better suggestions on how to integrate the proxied application(s) with your Apache instance.]
Setting up a front-end that can handle "Web Site Single Sign On" requires some planning and configuration but it is worth the effort. To make this easier, you'll want to use Apache-2.4. You probably are using this version, but Apache has become something of a workhorse, such that some sites update it much less frequently than in the past. Apache 2.4 includes mod_session and mod_auth_form which make it possible to set up form-based "web portal Single Sign On" sorts of tools with Apache for sites with multiple back-end application servers (often running on separate machine ports or sockets) combined under one outward facing set of URL/URIs. This pattern of use was so widespread with Apache that the 2.4 release added features to make it easier to do.
You asked about an "easy recommended" way to do what you have described. Well, you are on the right track. Apache's httpd is really useful for this kind of authentication/authorization and "user login" sort of application - so much so that it's become a staple tool for what you are trying to do.
You asked how to "deliver the user information" to the back-end server. You do that in the same way you handle state in any web application: with sessions and cookies. Session information contains key/value pairs encoded as an application/x-www-form-urlencodedstring. You can also create an HTTP_SESSION environment value that you back-end application can read from. Your Plack/Starman application has to be able to handle sessions and cookies (i.e. it has to be "session aware") if you want to use them there of course. Look at Plack::Middleware::Session for ideas on how to approach this.
For sure, setting up authentication with mod_auth_form is more complicated than Basic authentication. But with form based logins javascript can be used (judiciously), client applications can store form information locally for quick logins; as well, forms are flexible and can gather more data and pass more information to the user and some of the complexity (redirection after authentication) can be handled by Apache. Since they are just an HTML <form>, you can start simply and make them more elaborate as your site grows. That said you can have an Apache Reverse Proxy simply provide Basic Auth for your back-end.
Without seeing more details about your installation I can't say how/why you might need mod_rewrite per se, but Rewrite directives can play nicely with ProxyPass. Of course throughout your site you'd want to check for authentication and session information and redirect users to a login form where/when necessary. Using mod_auth_form makes this easier to implement at the cost of a somewhat more complicated configuration. As for the reverse prosy itself, you'd use ProxyPass in the normal way to pass requests to your back end:
ProxyPass /app http://[starmanhost]:3000/
Then you need configure or tweak your current Apache system to have Session On and require authentication for the URLs in question (unless the entire / requires authentication) in the standard Apache way:
<Location /app>
AuthType Basic
Session On
SessionCookieName session path=/
...
require valid-user
</Location>
etc. As the Apache docs point out (and you'll want to read mod_session, mod_proxy among others), you can pass session information around for use by back-end applications.
If the SessionHeader directive is used to define an HTTP request
header, the session, encoded as a application/x-www-form-urlencoded
string, will be made available to the application.
From mod_session documentation Integrating Sessions with External Applications.
For privacy/security you'll want to use mod_session_crypto and SSL if that's possible. As you note you will not need encryption to be "end to end" (i.e. HTTPS from client to outward facing front-end and between the reverse proxy and back-end applications) but if outside connections are https:// and you keep session information on the server (using mod_session_dbd as another response noted) using encrypted storage, you can avoid obvious threats inherent in sharing user session information across servers. The best part of this is you can add these layers one by one without having to modify your back-end applications extensively. This is the advantage of creating a solid "WebSSO server" front-end to handle logins.
Note that I've been using the term WebSSO here a bit loosely. Strictly speaking, WebSSO (and SSO) are much broader and more encompassing concepts with their own standards tracks and technologies (there are a couple Apache projects focused on this). This is why I tend to call the approach you are trying "Web Site SSO". Support for a wide range of authentication, programming language modules, proxying, and rewriting makes Apache's httpd the "swiss army knife/duct tape" of choice for handling logins and sessions in this way.
Your rational for doing this is sound, since you can avoid extra logins and confusing users (and their browsers). As well, by decoupling the authentication steps from your application and dedicating that task to Apache, you make it easier for developers to write back-end applications. Your question is very general though. I think you can start to try out some of the suggestions that begin to appear here and if you run into problems you can follow up with more specific questions focused on your implementation.
Get the Apache bits working correctly first (Session On; ProxyPass, <Location /app>) and make sure the right information is getting created, stored and passed on by the front-end. This will be very useful for lots of things going forward. Apache gurus can help here. Once you have the proper session information being passed to your back-end you can ask questions about how to access and use it in in your perl code with starman and plack. There may be missing or rough bits in tools and documentation but lots of sites want to do what you have described so these things will appear and continue to improve. Good luck.
References
A Gentle Introduction to Plack Sessions
Deploy Catalyst Applications with Starman and Apache
Using Apache mod_auth_form
Authentication in Apache2.4 using mod_auth_form and mod_dbd
Reverse proxying behind Apache
Apache's mod_session looks to be the component you are missing. Since the proxy is the gateway to the applications in the back-end, it can handle the authentication on the HTTP layer and pass back sessions as needed to the Perl script using the proxy entry.
Exposing the user information to the Perl application can happen in a few ways.
mod_session_dbd - is a module to store session information in a database. This could then be shared with the back-end server hosting the Perl application.
mod_session_cookie - is a module to store session information in a cookie on the browser of the client. Session variables would be stored in the cookie and the Perl application would retrieve them.
But, cookies or putting session variables in the URL open up security concerns. Cookies and headers can be modified.
mod_proxy should pass the session variables back to the applications in the form html.
http://httpd.apache.org/docs/trunk/mod/mod_session.html
Fiddler is a great tool for testing a wide variety of http scenarios. However Fiddler also blocks all kinds of traffic that it shouldn't. This intrusive behavior can be annoying and time consuming.
Is there a way to specify what Fiddler does and does not listen to? So I want to say only monitor and report on traffic going to localhost or www.google.com, everything else would be ignored.
Is that possible ?
Its just rather tedious to have to close fiddler whenever it blocks something it should not.
Fiddler acts as a system proxy, so you can't have some traffic flow through it and some not, unless you can configure the client to not use the proxy for some connections.
You can use Fiddler's filter options to determine what is captured and shown in the sessions window.
However, what does it block ? I use Fiddler extensively, and have no issues with connections being blocked. Perhaps there is another solution than closing Fiddler.
I faced the same problem when setting up Fiddler just now (Win7). My problem was that Fiddler (Fiddler2) was not detecting and using my corporate Proxy settings. I had to go and set them manually in Fiddler Options > Gateway
That is why all my non-local, non-intranet traffic was appearing to blackhole. Hope that helps.
So I want to make my own Internet Filter. Don't worry, i'm not asking for a tutorial. I'm just wondering if Fiddler would make a good backbone for it. I'm a little worried because it seemed that there's a few things Fiddler can't always pick up - or that there are workarounds. So, my question:
Would Fiddler grab all web data? i.e, chats, emails, websites, etc.
Are there any known workarounds?
Any other reasons not to use it?
Thanks!
I think you mean FiddlerCore rather than Fiddler. Fiddler(Core) is a web proxy meaning it captures HTTP/HTTPS traffic; it won't capture traffic that uses other protocols (e.g. IRC, etc). To capture traffic from other protocols, you'll need a lower-level interception point (e.g. a Windows Firewall filter) which will capture everything, but it will not be able to decrypt HTTPS traffic, and parsing / modifying the traffic will prove MUCH harder.
I'm using WCAT to load test my app, and I want to see the traffic in fiddler.
When I run the WCAT script, it runs OK,but I don't see any of the traffic in fiddler... Do I need to configure fiddler to proxy WCAT traffic?
The web app I am testing is on my local machine, but I'm not addressing it with "localhost", I'm using the name of my machine in my settings config. I don't have any filters set up in fiddler either.
EDIT:
Here's my transaction I'm testing with (the ipv4.fiddler is a recent addition as per a suggestion below):
transaction
{
id = "add a new user";
weight = 1;
request
{
verb = POST;
postdata = "Name=Bob+Smith&Gender=M&DateOfBirth=01%2F01%2F1970&Email=testuserdude" + rand("1","1000") + rand("1","1000") + "#example.com&Password=123456&ConfirmPassword=123456";
url = "http://ipv4.fiddler/TokenBasedLoginTests/Account/Register";
statuscode = 302;
}
close
{
method = ka;
}
}
Thanks
Matt
Per http://blogs.iis.net/thomad/archive/2010/05/11/using-the-wcat-fiddler-extension-for-web-server-performance-tests.aspx,
WCAT requests won't show up in Fiddler
nor can a proxy server be used with
WCAT.
The former part of that statement is implied by the latter part. It suggests that the WCAT team specifically removed the ability to use a proxy server, which seems like an odd choice, but might make sense if they thought the load would take down a proxy.
If you wanted, you could configure Fiddler to run as a reverse proxy, and then point WCAT at that reverse proxy; you'd see the traffic then, and Fiddler would redirect inbound requests to their actual destination. See http://www.fiddler2.com/redir/?id=reverseproxy
You might consider using the Visual Studio Web Test tools instead, as they do properly use the proxy (and hence Fiddler).
You could use an extension like this one http://blogs.iis.net/thomad/archive/2010/05/11/using-the-wcat-fiddler-extension-for-web-server-performance-tests.aspx
What happens when you use the server of http://ipv4.fiddler? Local traffic doesn't go through Fiddler, but it adds the ipv4.fiddler as a proxy on top of wininet (I may be getting that wrong and Eric Lawrence will correct me, I'm sure), and as a result, can capture local traffic?
I use Fiddler quite a bit to test web apps and services and always use ipv4.fiddler to capture my local traffic.
Hope this helps!
You can easily track WCAT traffic (very useful for debugging) using a transport level tool (such as Wireshark or Ethereal) rather than an HTTP proxy. These tools are able to capture traffic at the network card/packet level. All you need to do is...
a) Run a capture with a filter enabled to limit to traffic between client(s) and server and using a particular protocol (i.e. HTTP) - There's always a lot of unrelated traffic flowing through your network card and adding the filtering will make things easier. If you have multiple clients it might be best to run the capture on the server.
b) Tracing a stream (normally just click on one of the packets related to the request / response and rebuild it to a request / response.
Note that this will impact on throughput/performance. Best to turn it off for a real run! Hope this is helpful!
This is quite a straight forward question that I can't seem to find a comprehensive answer for. When using Selenium and Selenium proxy, how I can make the proxy catch outgoing xhr requests to specific uri's and modify the destination to a pre-mocked alternative.
I found this example form googling, http://www.sonatype.com/people/2009/10/selenium-part-4/ but it doesn't seem to explain how to write the mockHelper methods...
Thanks
Simon
This would require modification to the proxy server. There are no means otherwise to muck around with the response bodies. Your two options are to modify the proxy in the Selenium RC distribution, or alternatively, provide your own proxy server elsewhere. You can have the Selenium proxy connect to your proxy or you can configure the browsers to connect directly to your proxy. This would allow you to configure squid or whatever your comfortable with to deal with the request.