I'm developing a web page using Flask, on an Apache server where the Server is enforcing basic authentication. That is, a user accessing a page on the server is presented with a login screen by Apache, and the login credentials checked prior to passing the request to my page.
The question is whether, and how, I can access the user name from my flask/python code. When using PHP instead of flask/python, on the same server, it is straightforward: The username is a available as a $_SERVER variable (available twice it seems, as the value for keys PHP_AUTH_USER, and also AUTHENTICATE_CN). I'm guessing/hoping that Apache would similarly make the authenticated username available to flask (perhaps through WSGI somehow), but I can't find it.
I've tried displaying all the key/value pairs in request.headers, but the username isn't there. Is there somewhere else I should look?
You can find authentication information in Flask from the request object.
from flask import request
def my_view():
auth = request.authentication
username = auth.username
password = auth.password
...
Note however that if you're using apache mod_wsgi, you'll need to turn on the WSGIPassAuthorization directive in your virtualhost config. Otherwise apache will consume the authentication header and won't pass it to the WSGI layers.
<virtualhost *:443>
...
WSGIPassAuthorization On
...
</virtualhost>
more info here and here.
I eventually found it, it's available as:
request.environ.get('REMOTE_USER')
Not knowing this wasn't my only problem however, in case
it's useful for anyone, here's the story:
Firstly I tried to find out if WSGI was passing the authentication
info through to flask. This answer to a different question was very
helpful (it shows you how to see everything WSGI is providing before
it gets to flask):
https://stackoverflow.com/a/1151129/1956954
When I list the WSGI info as per that answer, it didn't have the
user information. But that turned out to be because the setup for
apache basic authentication in the relevant sites-enabled apache
config file was configured for the document root (a htdocs folder).
Since I'm using WSGI to redirect the relevant requests to a folder
outside of the document route, I didn't actually have authentication
turned on for my page. (And I didn't notice that because I had accessed
some pages under htdocs, been forced to authenticate, and assumed that
I wasn't being asked to authenticate when I went to my flask pages
because the authentication had been cached).
Creating another section in the relevant apache sites-enabled
file setting up authentication for my flask directories enabled authentication
Related
I am running a website with Apache/2.4.53 (Debian) and MapServer 7.6.2. I have set up a secure part of the web site following instructions here: https://www.digitalocean.com/community/tutorials/how-to-set-up-password-authentication-with-apache-on-ubuntu-14-04
I would now like to display some geospatial data held in MapServer via an OpenLayers WFS map on the secure site. The challenge I have is that once a user logs in, they can see the MapServer access details in the OpenLayers script so have the server URL and mapfile name, and can access this outside the secure site i.e. without going through Apache authentication.
There was some discussion about securing MapServer 11 years ago (https://gis.stackexchange.com/questions/5686/securing-wms-against-unauthorized-access) but this didn't seem applicable.
As I understand it MapServer is accessed through a CGI to which requests are redirected through Apache. Would moving the /usr/bin/mapserv executable into a folder managed by Apache2 work?
(as seems to be suggested here: /cgi-bin .htaccess or apache2.config rules bring up password dialog but cgi executes before authorization)
Any advice appreciated.
We have a Java/Jetty server. The servlets on this server are called by some of our internal applications over http.
I have been asked to create a webapp /website which will use many of these servlets / api.
However this is an external customer facing website and needs to be served over https / ssl. The servelet urls look like
http://internalServer:9999?parameters.
Now my webapp is ready and has been deployed on Apache on Debian. Everything works fine but as soon as I enable
https/ssl the backend calls do not go through. On chrome I get "Mixed content. Page was loaded on https but is requestig resource over http...". On Safari I get -could not load resource due to access control checks.
I understand the reasons for these errors but I would like to know ways to solve this.
I have full control over apache server and website code.
I have very limited control over internal jetty server and no control over servelt code.(don't want to mess with existing apps).
Is there something I can do just with apache configuration? can I use it as a reverse proxy for the Jetty(http) server?
Thanks for your help.
"Mixed content. Page was loaded on https but is requestig resource over http..."
That error message means your HTML has resources that are being requested over http://... specifically.
You'll need to fix your HTML (and any references in javascript and css) that request resources (or references resources) to also use https://....
If you try to call an http service from an https site you will have Mixed content error.
You can avoid that error using apache2 proxy settings inside your example.org.conf
You can find it inside the folder /apache2/sites-enabled
Add some code:
<VirtualHost *:443>
...
ProxyPass /service1 http://internalServer:9999
ProxyPassReverse /service1 http://internalServer:9999
</VirtuaHost>
From your https site you have to fetch the url
https://example.org/service1`
to reach the service.
In that way you can call your services http from a https site.
i wondering, it is possible to redirect ALL WEBSITE to a URL(authentication page) in localhost (wampserver)..
after client login (in the authentication page) with correct ID and PASSWORD, then the client will be able to access to any WEBSITE.
You could setup basic authentication in apache. Edit httpd.conf by clicking through from the WampServer icon and follow these instructions. However, instead of using <Directory "/var/www/html/protected"> and doing it for each vhost, use <Location />. This is because each site will match that location directive so will all need to run the same authentication before sites will be shown.
If you didn't want to use basic auth in this manner, then I'd suggest you setting up shared authentication on your sites (like stack uses OpenID) or looking at something like CORS, but that seems like a lot of work.
The final thing I'd point out is IP restriction. We have some clients/staff/etc that access our dev servers but it's all locked down to specific IPs and luckily so far everyone who's needed it has had a static IP. This may not be an option.
Our client has a set of (5-6) intranet/internet applications either custom developed or 3d-party, located in various web servers, which applications we cannot modify/control.
We have developed a web portal application (A) and the client wants that all its other applications (B) are accessed only via A, meaning that if a user enters directly the application url for B, he gets an error page telling that access is allowed only via A. So, user has to log in to application A and then click a link to application B to access it. This requirement has been asked for security reasons and to make A act as an access gateway to other applications (B).
Is this possible and how can we implement it? Should we use another web server on the top acting as a proxy to all other applications (B) or is there a better solution for this? And if we use another web server as a proxy should we implement the referrer logic with a user id - token approach combined with appropriate session cookies, so that the application B's url cannot be hacked and is unique for each user and session?
Sorry if I stated my questions unclearly or in a wrong way, but I'm unfamiliar with network/system administration and web servers. I can provide more details where needed.
there are different approaches here:
1. using firewall setup access to B http{s} port only from A IP address.
2. set Directory restriction in httpd.conf for aps B directory like:
<Directory "/var/www/B">
AllowOverride None
Order allow,deny
Allow from <IP of A>
</Directory>
in APS A create link (http://ip_A/accesstoB/somepath/script.php) that will Proxied to B using .htaccess rule like:
RewriteRule ^accesstoB/(.*)$ http://<ip_B>/$1 [P]
in this example: customer accessing http://ip_A/accesstoB/somepath/script.php link will be proxied to http://ip_B/somepath/script.php
You begin with restricting access to B Applications by using web server conf files or with firewall restrictions based on ip.
Then you redirect all these requests to new wrapper app you will develop.
With this wrapper app you do whatever authentication you like, then your wrapper app does the http/https request(via libcurl or etc.) and echoes the response.
We have an application runing on Weblogic 10.3, with authentication provided on the application itself. We want to put the Weblogic behind an Apache server. The idea is that we will have some public content on the Apache server, and the application will be accessed through the reverse proxy. That's pretty much very standard. The issue comes with the fact that there are some contents on the Apache server that can only be accesssed if the user has logged in the application. So basically the Apache server will server three type of contents, on diferent URIs:
/ -> Will contain the public information, and will be server by the Apache
/myApp - > Will be redirected by the Apache to the weblogic behind
/private - > Will contain the private static information. This should only be accessed if the user has previously logged successfully in myApp.
My question (I'm a total newbie with Apache) is if this possible. My idea is that the application can put a cookie on the responses indicating if the user has logged on the application, and that the Apache will check for that cookie when the user tries to access /private.
Any thoughts?
The / public information is no problem, it's straightforward. Using ProxyPass or ProxyPassMatch to reverse proxy "/myApp" to your internal Weblogic server is also straightforward. You may need to use a couple of other options to make sure proxy hostname and cookie domains are setup correctly. But setting up static protected infrormation in "/private" is going to be a little more tricky.
1) You can check the existence of the cookie set by myApp using mod_rewrite, something like this:
RewriteCond %{HTTP_COOKIE} !the_name_of_the_auth_cookie
RewriteRule ^private - [F,L]
The problem with checking a cookie through something like this is that there's no way to verify that the cookie is actually a valid session. People can arbitrarily create a cookie with that name and be able to access the data in /private.
2) You could set it up so that anything something in "/private" is accessed, the request is rewritten to a php script or something that can check the cookie to ensure that it's a valid session cookie, then serve the requested page. Something like:
RewriteRule ^private/(.*)$ /cookie_check.php?file=$1 [L]
So when someone accesses, for example, "/private/reports.pdf", it gets internally redirected to "/cookie_check.php?file=reports.pdf" and it's up to this php script to access whatever it needs to in order to validate the cookie that /myApp has setup. If the cookie is a valid session, then read the "reports.pdf" file and send it to the browser, otherwise return FORBIDDEN.
I think this is the preferable way of handling this.
3) If you can't run php or any other scripts, or the cookie cannot be verifed (like with a database lookup of session_id or something similar), then you'll have to proxy from within WebLogic. This would be more of less the same basic idea as having access to "/private" through "cookie_check.php" except it's an app on the WebLogic server. Just like /myApp, you'll need to setup a reverse proxy to access it, then this app will get the request (which has been internally rewritten from "/private/some_file") check the cookie's validity, read the "some_file" file ON THE APACHE SERVER, then send it to the browser, or send FORBIDDEN. This is the general idea:
ProxyPass /CheckCookie http://internal_server/check_cookie_app
RewriteCond %{REMOTE_HOST} !internal_server
RewriteRule ^private/(.*)$ /CheckCookie?file=$1 [L]
This condition reroutes all requests for "/private" that didn't originate from "internal_server" through the /CheckCookie app, and since the app is running on "internal_server" it can access the files in "/private" just fine. This is kind of a round-about way of doing this, but if the validity of session cookies issued by /myApp can only be checked on the WebLogic server, you'll have to reroute requests back and forth or something similar.