I'm planning on using CouchDB's built-in cookie authentication for my app (note that this isn't a CouchApp, I'm using a web server between my client and db).
So when a user first logs in with their credentials:
Credentials are sent to CouchDB from web client via web server
CouchDB authenticates credentials and returns a Set-Cookie header
This header is sent to the web client and means that all subsequent requests for database operations just pass on the Cookie header to CouchDB via the web server.
Whilst I've been able to ascertain that:
You can keep using [the cookie] token for 10 minutes by default. After 10 minutes you need to authenticate your user again. The token lifetime can be configured with the timeout (in seconds) setting in the couch_httpd_auth configuration section.
It isn't clear to me if this 10 minute period is (or can be set to be) a sliding window.
By this I mean; if the user continues to use the application for the whole 10 minutes (sending the cookie along on each request), will the cookie automatically be re-set (in a similar way to FormsAuthentication cookies in .NET) until a period of in-activity for 10 minutes?
References used
http://guide.couchdb.org/draft/security.html#cookies
http://wiki.apache.org/couchdb/Security_Features_Overview
For a browser, the (configurable) 10-minute period is a sliding window. Every time CouchDB responds to a request, it will update the cookie to a new value, effectively refreshing the login.
For a client, you must remember to reset the cookie value when you see a Set-Cookie header (or pass it through to your own client in your case).
For example, I have a short timeout (30 seconds):
$ curl http://admin:admin#localhost:5984/_config/couch_httpd_auth/timeout
"30"
Next I will:
Log in
Wait a little while
Check my session with the cookie, before the timeout
Wait for the timeout
Check my session with the cookie again, after the timeout
(Quickly) check my session with the new cookie CouchDB set in step 3
Notice that the first confirmation has {"name":"me"} (I am logged in); the second has {"name":null} (I am logged out); but the third has {"name":"me"} again (I am still logged in due to using the updated cookie).
$ curl -X POST -i localhost:5984/_session -d name=me -d password=secret
HTTP/1.1 200 OK
Set-Cookie: AuthSession=bWU6NEY5QjQ3QTA6Ao6zetUZUxkno37ULd2qdRRjmsc; Version=1; Path=/; HttpOnly
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Sat, 28 Apr 2012 01:28:00 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 35
Cache-Control: must-revalidate
{"ok":true,"name":"me","roles":[]}
$ sleep 20
$ curl -i localhost:5984/_session -H Cookie:AuthSession=bWU6NEY5QjQ3QTA6Ao6zetUZUxkno37ULd2qdRRjmsc
HTTP/1.1 200 OK
Set-Cookie: AuthSession=bWU6NEY5QjQ3QkM6WonDdsAdO8p7QUlLWCZQXVAfcvU; Version=1; Path=/; HttpOnly
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Sat, 28 Apr 2012 01:28:28 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 165
Cache-Control: must-revalidate
{"ok":true,"userCtx":{"name":"me","roles":[]},"info":{"authentication_db":"_users","authentication_handlers":["oauth","cookie","default"],"authenticated":"cookie"}}
$ sleep 10
$ curl -i localhost:5984/_session -H Cookie:AuthSession=bWU6NEY5QjQ3QTA6Ao6zetUZUxkno37ULd2qdRRjmsc
HTTP/1.1 200 OK
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Sat, 28 Apr 2012 01:28:43 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 140
Cache-Control: must-revalidate
{"ok":true,"userCtx":{"name":null,"roles":[]},"info":{"authentication_db":"_users","authentication_handlers":["oauth","cookie","default"]}}
$ curl -i localhost:5984/_session -H Cookie:AuthSession=bWU6NEY5QjQ3QkM6WonDdsAdO8p7QUlLWCZQXVAfcvU
HTTP/1.1 200 OK
Set-Cookie: AuthSession=bWU6NEY5QjQ3RDA69pqrNVd-ClZ7_v4SkcghdZRRhCs; Version=1; Path=/; HttpOnly
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Sat, 28 Apr 2012 01:28:48 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 165
Cache-Control: must-revalidate
{"ok":true,"userCtx":{"name":"me","roles":[]},"info":{"authentication_db":"_users","authentication_handlers":["oauth","cookie","default"],"authenticated":"cookie"}}
In CouchDB 1.2.0 and later, you can set _config/couch_httpd_auth/allow_persistent_cookies to "true" and it makes things easier to see. The cookie will have an obvious "Expires" flag which you can see is always set to the current time plus your timeout value.
Related
I added some custom fonts to my website and uploaded them to AWS S3 + CloudFront.
A lot of topics here describe this problem but non of them are solving my issue.
Using curl I get this output:
curl --head https://cdn.mzguru.de/fonts/sourcesanspro/source-sans-pro-v12-latin-ext_latin-700.woff2
HTTP/1.1 200 OK
Content-Type: binary/octet-stream
Content-Length: 25348
Connection: keep-alive
Date: Tue, 22 Oct 2019 11:54:18 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Last-Modified: Fri, 12 Apr 2019 10:54:26 GMT
ETag: "639c2738552a0376c91e7d485e476fda"
Cache-Control: max-age=62208000
Accept-Ranges: bytes
Server: AmazonS3
X-Cache: Hit from cloudfront
Via: 1.1 bae3e24625567f5728a5caa96d6b7669.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: FRA53
X-Amz-Cf-Id: iAy-QTfuV9ZqwmaRjXE0ramVSgsZkA6MtRmQOKDSonf6I8OabrpLZA==
Age: 12818
Within Chrome I get this error:
Access to font at 'https://cdn.mzguru.de/fonts/sourcesanspro/source-sans-pro-v12-latin-ext_latin-700.woff2' from origin 'https://www.monteurzimmerguru.de' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
This is the point where I do not understand the problem. The error message says: "No 'Access-Control-Allow-Origin' header is present"
But in the curl request I see this header. What is wrong?
Thank you
EDIT
I have attached a screenshot with the error messages.
EDIT 2: AWS Interface changed (2022)
Please take a look at #James Dean post.
1.) Do I need to tick the options box?
2.) I can not find the settings you describe. I guess the UI changed in the meanwhile.
Your S3 CORS configuration is correct based on below output:
>curl -vk "https://cdn.mzguru.de/fonts/sourcesanspro/source-sans-pro-v12-latin-ext_latin-700.woff2" -H "Origin: https://www.monteurzimmerguru.de"
< HTTP/2 200
< content-type: binary/octet-stream
< content-length: 25348
< date: Thu, 24 Oct 2019 12:19:41 GMT
< access-control-allow-origin: *
< access-control-allow-methods: HEAD, GET
< access-control-max-age: 3000
< last-modified: Fri, 12 Apr 2019 10:54:26 GMT
< etag: "639c2738552a0376c91e7d485e476fda"
< cache-control: max-age=62208000
< accept-ranges: bytes
< server: AmazonS3
< x-cache: Hit from cloudfront
However, Chrome/Browser is making OPTIONS/Preflight request on CloudFront and options request is not allowed on cloudfront currently. Only Head and GET are allowed.
curl -X OPTIONS "https://cdn.mzguru.de/fonts/sourcesanspro/source-sans-pro-v12-latin-ext_latin-700.woff2" -H "Origin: https://www.monteurzimmerguru.de"
>This distribution is not configured to allow the HTTP request method that was used for this request
To fix this , you need to do it:
In the CloudFront cache behaviour, you need to allow GET,HEAD and OPTIONS
In Cache behaviour, cache based on selected header, you should select Origin
Invalidate cache once and test it again.
You have to update,
Query String Forwarding and Caching to Forward all, cache based on all
in cloudfront Cache Behavior Settings ( cloudfont -> select one -> edit )
My app is required to support users logged in via SSO on a 3rd party server.
I configured settings.py based on the docs, i.e.
MIDDLEWARE_CLASSES = [
'...',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.PersistentRemoteUserMiddleware',
'...',
]
AUTHENTICATION_BACKENDS = [
'django.contrib.auth.backends.RemoteUserBackend',
]
I tried to test this using Postman on a couple of the app's URLs with no auth and with basic auth (user is defined) and, of course, with REMOTE_USER (and/or HTTP_REMOTE_USER header set).
In all cases I get a 401 - unauthorized code. Moreover, the breakpoint in authenticate is never called. The process_request in the middleware is called, but the REMOTE_USER header is not in request.META.
What else do I need to configure (in Django, Postman - or better still Apache) so that the REMOTE_USER will be set?
My knowledge of Apache is minimal, so a link to an example will help a lot.
The closest "solution" I saw is this, but it seems that the person circumvented the proper way to do this.
UPDATE
The Postman request is simply to one of the basic services which requires users to be logged in (#login_required decorator in Django)
I've tried with both basic auth and no auth.
The reply is a 401 without additional information.
>curl -i -H 'REMOTE_USER: user' localhost:9000/project/files/
HTTP/1.0 401 Unauthorized
Date: Sun, 17 Dec 2017 13:38:38 GMT
Server: WSGIServer/0.1 Python/2.7.10
Expires: Sun, 17 Dec 2017 13:38:38 GMT
Vary: Cookie
Last-Modified: Sun, 17 Dec 2017 13:38:38 GMT
Location: /accounts/login/?next=/project/files/
Cache-Control: no-cache, no-store, must-revalidate, max-age=0
X-Frame-Options: SAMEORIGIN
Content-Type: text/html; charset=utf-8
Same command with cURL. The Location seems to suggest it tried to redirect to the login page (which should not happen)
By registering your application you can increase your rate limit for GitHub's API from 60 to 5000 requests[1]. You don't have to use OAuth and can simply pass you're client ID and secret in the URL to have GitHub recognize your application[2]. But when I curl the rate limit check:
curl -i https://api.github.com/ratelimit?client_id=xxx&client_secret=yyy
The following is returned:
HTTP/1.1 200 OK
Server: GitHub.com
Date: Sat, 13 Jul 2013 01:53:50 GMT
Content-Type: application/json; charset=utf-8
Status: 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 51
X-RateLimit-Reset: 1373683093
X-GitHub-Media-Type: github.beta
X-Content-Type-Options: nosniff
Content-Length: 55
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: ETag, Link, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes
Access-Control-Allow-Origin: *
ETag: "[redacted]"
Cache-Control: max-age=0, private, must-revalidate
Vary: Accept-Encoding
{"rate":{"limit":60,"remaining":51,"reset":1373683093}}
Does anyone know what I'm doing wrong? Do I really have to use the full OAuth?
Putting the URL in quotes when running the command fixed the problem.
It's worth noting that you can also register "Personal Access Tokens" from the Applications menu option inside GitHub. This gives you a token with the increased 5,000 API calls/hour without having to do the OAuth dance.
I am a bit stuck in authenticating my app and get an access token, when following this instructions: http://developers.flattr.net/v2/
Step 1, Authenticate works fine. I get back the code, and my app is listed in my Settings/Applications with the correct scope.
Then I try to get the access token via the following curl command:
curl -v --user MY_KEY:MY_SECRET -H "Content-Type: application/json"\
-X POST -d '{"grant_type": "authorization_code",\
"redirect_uri": "http://localhost/", "code": "MY_CODE"}'\
https://flattr.com/oauth/token
Unfortunately I always get "invalid_request"
< HTTP/1.1 400 Bad Request
< Strict-Transport-Security: max-age=500
< Set-Cookie: PHPSESSID=d9972s9r5a7t4p0ch4chc4dqh2; path=/; domain=.flattr.com; HttpOnly
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store
< Pragma: no-cache
< Content-Type: application/json; charset=utf-8
< Content-Length: 291
< Connection: close
< Date: Wed, 16 Nov 2011 22:38:30 GMT
< Server: lighttpd
<
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
{"error":"invalid_request","error_description":"The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed."}
Thanks!
I found a bug in the process and it is now smashed. Should be working smooth if you try the request again!
I'm building a JSON API on top of devise in order to be able to communicate from mobile devices.
So far so good, I am able to create a user account, to get an auth_token. But when I am trying to perform a PUT request, I get some problems , for example the update action for the user. The behavior is really stange, and I can't figure out what is wrong.
curl -i -H "Accept: application/json" 'http://localhost:3000/users' -X PUT -d 'auth_token=A830ALUv7ztTdSfl3qxFgi13BJpEf6VzNYe4yk8rEhVxbYYlOc0YMtTGMxkz&user[name]=plop'
Returns
HTTP/1.1 401 Unauthorized
Connection: close
Date: Wed, 02 Mar 2011 06:41:29 GMT
Content-Type: application/json; charset=utf-8
Cache-Control: no-cache
X-UA-Compatible: IE=Edge
X-Runtime: 0.157513
Transfer-Encoding: chunked
{"error":"You need to sign in or sign up before continuing."}
On the logs on the server i get this .... Really strange.
Started PUT "/users" for 127.0.0.1 at 2011-03-01 22:41:29 -0800
Processing by Users::RegistrationsController#update as JSON
Parameters: {"auth_token"=>"A830ALUv7ztTdSfl3qxFgi13BJpEf6VzNYe4yk8rEhVxbYYlOc0YMtTGMxkz", "user"=>{"name"=>"plop"}}
Completed in 1ms
Whereas if I modify just the name of the post value from user to users form example, the request works
HTTP/1.1 200 OK
Connection: close
Date: Wed, 02 Mar 2011 06:43:30 GMT
Content-Type: application/json; charset=utf-8
ETag: "5e1311709931861e469ce2c8a3b2d0e6"
Cache-Control: max-age=0, private, must-revalidate
X-UA-Compatible: IE=Edge
Set-Cookie: _u_session=BAh7CEkiGXdhcmRlbi51c2VyLnVzZXIua2V5BjoGRVRbCEkiCVVzZXIGOwBGWwZvOhNCU09OOjpPYmplY3RJZAY6CkBkYXRhWxFpUGGaQG%2FaX1pAfhpAaRpAexpAGkAaQ1JIiIkMmEkMTAkMDVBeDczV29UdVFEZHQxZ1JjN0NXdQY7AFRJjW9uRGlzcGF0Y2g6OkZsYXNoOjpGbGFzaEhhc2h7BjoLbm90aWNlSSIrWW91IHVwZGF0ZWQgeW91ciBhY2NvdW50IHN1Y2Nlc3NmdWxseS4GOwBUBjoKQHVzZWRvOghTZXQGOgpAaGFzaHsASSIPc2Vzc2lvbl9pZAY7AEYiJTcyNmIyZjJiODZhOTBiNjUwZDlhZmIwMzA5MTRkMTlm--0e15953fd7edecb0e08255349c4e55f1eddc8d81; path=/; HttpOnly
X-Runtime: 0.162436
Transfer-Encoding: chunked
{"redirect":"/","status":"ok"}
I precise that, even without my code(For the API) I can't perform this request !!!!
Thanks for your help !
I don't believe that Devise handles JSON calls, there is an open issue on github that is scheduled for the 1.3 release to address this problem.