I have the project to set up a git server for my school with a web interface to create repositories and display them. This web part will be handled by Django, which knows the users.
Now the problem: I want authentication to pull and push private repositories but I can't use SSH to handle that part (the IT guys don't want to do support on that). The HTTP protocol is read-only without "complexe WebDAV" (according to the official doc) and use .htaccess as authentication. The problem with .htaccess is to manage them with Django: I tried to use a Django user's hash in it but it didn't work. And, finally, the Git protocol is read-write but it lacks authentication.
Summing up:
I want authentication linked with Django's users database. (To avoid having multiple places with same data)
No SSH
Avoid WebDAV and .htaccess
With these constraints I found that rewriting the git daemon (code on github) to handle authentication would be an idea but I don't know for sure how a Git client would react to that.
If you guys have another idea or want to tell me how better it would be to use WebDAV/.htaccess/..., I will be glad to hear it !
You could setup an Apache server (even one with https like I do in my config!), except you would ask your wsgi application to handle the authentication.
See "Access Control Mechanisms", in the mod_wsgi:
AuthType Basic
AuthName "Top Secret"
AuthBasicProvider wsgi
WSGIAuthUserScript /usr/local/wsgi/scripts/auth.wsgi
Require valid-user
The auth.wsgi script can check the credentials against your Django users database.
That solution means calling the git-http-backend (smart http transport), which is ore efficient than WebDAV.
Related
I'm working on a Django 3.2 project which is hosted using Apache 2.4 server. The user authentication in this project is handled using HTTP Basic Authentication configured using LDAP.
I have implemented a sign up feature for new users. For that I have created the necessary form, view, template and url pattern in the Django project. The urlpattern to visit the sign up form is /signup.
My goal is to make the sign up urlpattern accessible to anyone i.e. prevent the Basic Authentication from showing when the sign up urlpattern is requested by user in the browser.
JFI, the complete Apache configuration is already complete and works already.
To achieve this, I have used the "LocationMatch" directive in the Apache configuration within the VirtualHost directive:
...
<LocationMatch "^/signup$">
Require all granted
</LocationMatch>
...
With this the Basic Authentication is removed when /signup URI is requested, but the server always redirects to another url which ultimately requires authentication hence giving the basic auth pop-up.
$ curl -I https://*****.com/signup
HTTP/1.1 302 Found
...
I have tried to redirect the request explicitly to /signup whenever the is /signup. This ends up in an endless loop of redirections.
RewriteEngine on
...
RewriteRule ^/signup$ /signup [R=301,L]
I have also tried other ways by setting environment variables within Apache configuration, I have restarted Apache whenever a change was done in config, I have cleared browser cache etc., but nothing seems be working.
FYI, I can access the /signup url successfully after logging into the application which is not useful for me.
I'm afraid I cannot share the complete source (apache config, django source etc.) here as the project is not completely open source yet. But I'm sure your suggestions would surely help me in some way.
I want to fix the redirection. I have no clue what I'm missing out here.
I have a number of .html files on my web-server which I store in a specific folder. I have to protect them from unwanted users and let only a few people to be able to access this folder.
I would like to protect this specific folder, so users have to log in, but I don't want to use any PHP framework etc. It's only a simple HTML website created without PHP.
I have my own dedicated server, so there are some options to do it. For now I did basic HTTP Auth based on .htaccess and .htpasswd files, but I've just read it's no really secure because password is sent as plain text. I've found a similar option called .htdigest, but maybe there are more secure and also easy to set up ways to secure folder? Hope someone can recommend me a method to make it secure? Here is what I have on my server:
using CloudFlare Service (paid plan) which allows me to use SSL,
can install additional modules if needed.
Thank you for help!
you can use allow/deny directive
Order allow,deny
Deny from all
it will give user response code 403 forbidden page but if you want to return 404 response code then you can use below
RedirectMatch 404
references : http://httpd.apache.org/docs/current/sections.html
I'm trying to configure cubesviewer and try out the setup.
I've got the app installed running, along with cubes slicer app too.
However, when I visit the home page
http://127.0.0.1:8000/cubesviewer/
it fails popping up an error "Error occurred while accessing the data server"
Debugging with the browser console, shows a http status 403 error with the url http://localhost:8000/cubesviewer/view/list/
After some googling and reading, I figured I'll need to add rest frame auth settings. (as mentioned here.).
Now after running migrate and runserver, I get 401 error on that url.
Clearly I'm missing something with settings.py , Can somebody help me out.
I'm using the cubesviewer tag v0.10 from the github repo.
And find my settings here. http://dpaste.com/2G5VB5K
P.S: I've verified Cubes slicer works separately on its' own.
I have reproduced this. This is error may occur when you use different URL to access a website and to access related resources. For security reasons, browsers allow to access resources from exactly the same host as the page you are viewing.
Seems you are accessing the app via http://127.0.0.1:8000, but you have configured CubesViewer to tell clients to access the data backend via http://localhost:8000. While it's the same IP address, they are different strings.
Try accessing the app as http://localhost:8000.
If you deploy to a different server, you need to adjust settings. Here are the relevant configuration options, now with more comments:
# Base Cubes Server URL.
# Your Cubes Server needs to be running and listening on this URL, and it needs
# to be accessible to clients of the application.
CUBESVIEWER_CUBES_URL="http://localhost:5000"
# CubesViewer Store backend URL. It should point to this application.
# Note that this must match the URL that you use to access the application,
# otherwise you may hit security issues. If you access your server
# via http://localhost:8000, use the same here. Note that 127.0.0.1 and
# 'localhost' are different strings for this purpose. (If you wish to accept
# requests from different URLs, you may need to add CORS support).
CUBESVIEWER_BACKEND_URL="http://localhost:8000/cubesviewer"
Alternatively, you could change CUBESVIEWER_BACKEND_URL to "http://127.0.0.1:8000/cubesviewer" but I recommend you to use hostnames and not IP addresses for this.
Finally, I haven't yet tested with CORS support, but check this pull request if you wish to try that approach.
I use geodjango to create and serve map tiles that I usually display into OpenLayers as openLayers.Layer.TMS
I am worried that anybody could grab the web service URL and plug it into their own map without asking permission, and then consume a lot of the server's CPU and violate private data ownership. On the other hand, I want the tile service to be publicly available without login, but from my website only.
Am I right to think that such violation is possible? If yes, what would be the way to be protected from it? Is it possible to hide the url in the client browser?
Edit:
The way you initiate tile map service in OpenLayers is through javascript that could be read from client browser like this:
tiledLayer = new OpenLayers.Layer.TMS('TMS',
"{{ tmsURL }}1.0/{{ shapefile.id }}/${z}/${x}/${y}.png"
);
Its really easy to copy/paste this into another website and have access to the web service data.
How can I add an API Key in the url and manage to regenerate it regularly?
There's a great answer on RESTful Authentication that can really help you out. These principals can be adapted and implemented in django as well.
The other thing you can do is take it one level higher than implementing this in django but use your webserver.
For example I use the following in my nginx + uwsgi + django setup:
# the ip address of my front end web app (calling my Rest API) is 192.168.1.100.
server {
listen :80;
server_name my_api;
# allow only my subnet IP address - but can also do ranges e.g. 192.168.1.100/16
allow 192.168.1.100;
# deny everyone else
deny all;
location / {
# pass to uwsgi stuff here...
}
}
This way, even if they got the URL, nginx would cut them off before it even reached your application (potentially saving you some resources...??).
You can read more about HTTP Access in the nginx documentation.
It's also worth noting that you can do this in Apache too - I just prefer the setup listed above.
This may not answer your question, but there's no way to hide a web request in the browser. To normal users, seeing the actual request will be very hard, but for network/computer savvy users, (normally programmer who will want to take advantage of your API) doing some sniffing and finally seeing/using your web request may be very easy.
This you're trying to do is called security through obscurity and normally is not very recommended. You'll have to create a stronger authentication mechanism if you want your API to be completely secure from non authorized users.
Good luck!
I am developing an app, which I will deploy on Heroku. The app is only used within an iframe on another site, so I don't care about the domain name. I plan to deploy my app on example.herokuapp.com instead of using a custom domain on example.com.
My app uses cookies, and I want to be sure that others cannot manipulate my cookies to protect my app against session fixation and similar attacks. If attacker.herokuapp.com is able to set a cookie for herokuapp.com, browsers will not be able to protect me, since herokuapp.com is not a public suffix. See http://w2spconf.com/2011/papers/session-integrity.pdf for a detailed description of the issue.
My question is: When browsers can't protect my users, will Heroku do it by blocking cookies for herokuapp.com?
Just wanted to post an update for anyone who ran across this question as I did. I was working on a similar problem, except that I wanted to purposefully allow access to the same cookie from two different heroku apps.
"herokuapp.com" and "herokussl.com" are now on the Public Suffix List, so your cookies should be safe if they are set for one of those domains. I ended up having to use custom domains in order to share cookies across both apps.
Heroku also released an article on the topic: https://devcenter.heroku.com/articles/cookies-and-herokuapp-com
I just tried to add a cookie from my Heroku app with the response header Set-Cookie: name=value;Path=/;Domain=.herokuapp.com, and to my disappointment, I could see the header intact in my browser. So the Heroku infrastructure does not detect and remove this cross-app supercookie.
I see three possible ways to protect a Heroku app against cross-app supercookies:
Don't use cookies at all.
Use a custom domain.
Verify that each cookie was actually set by your app, and restrict it to the client's IP address by checking the X-Forwarded-For header.
My feature request to Heroku would be that they should filter HTTP responses that goes through their HTTP routing, such that applications hosted on their infrastructure cannot set cookies with Domain=herokuapp.com.
It seems to me that, as long as you set the cookie for example.herokuapp.com, then the cookie is safe from manipulation. The cookie will only be presented to the app running on example.herokuapp.com and to herokuapp.com (where no app runs).