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.
Related
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 have an unusual problem when I used an iframe on a site i'm building. The hotlink protection is off on both servers. The iframe still doesn't work. both are ssl sites. What is strange is I can add a subdomain to the website where the webpage for the iframe, and redirect to the other server, and the site shows up in the iframe after that, but directly it doesn't. Is there by chance a setting on the webserver that doesn't allow external iframes? Is it better to just leave this alone and do a subdomain hop (I'm wondering if the web host guys at hostgator did that on purpose for security, and I should just do the hop method i stumbled upon). both servers are running nginx, webserver is using nginx+apache
Using iframes on external sites can be prevented with HTTP Header like X-Frame-Options
Documentation can be found from here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
This header can be set by either the web server or the software that is running on the web server.
well, I got it working. in the .htaccess (after I turned back on hotlinking)
I wrote after the RewriteEngine on line:
AllowOverride All
Header set X-Frame-Options "ALLOW-FROM https://www.theothersite.com/"
and it works! of course I added the http and https urls too on the exception list. now I can Iframe and use document-forms POST method
I have an AJAX site leuker.nl and when googlebot comes along the site is started and it will retrieve an XML file from my backend server that contains site text.
The HTTP GET request used to retrieve the file returns a HTTP error 498.
Looking on LINK it explains that is concerns an invalid/expired token (esri) returned by "ArcGIS for Server".
I don't understand this error, I don't even use ArcGIS and never heard of it before.
Andy idea how to solve this?
In the backend I use Apache Httpd 2.4 in combination with Tomcat 8.0. Apache proxy requests to Tomcat through an ajp connector. The XML file requested is directly returned by Apache.
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.
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