Description of problem: In version 1.3 of calamari API operations required cookie authentication in 1.4 this was broken and is not being checked Version-Release number of selected component (if applicable): 1.4.0 on How reproducible: 100% Steps to Reproduce: 1. visit /api/v2/cluster 2. notice that you are redirected to a login page Actual results: all api endpoints are available without authentication Expected results: api is restricted to authenticated users. Additional info:
State so far: This work is adding cookie based auth to the 1.4 branch of calamari. I am planning on using sqlite3 to serve as Django's back-end to store user credentials. My work in progress is at https://github.com/ceph/calamari/tree/wip-trim Current issue is this: > /root/calamari/rest-api/calamari_rest/views/v1.py(543)login()->None -> user = authenticate(username=username, password=password) (Pdb) pp authenticate(username=username, password=password) *** DatabaseError: DatabaseError("DatabaseWrapper objects created in a thread can only be used in that same thread. The object with alias 'default' was created in thread id 139796691641040 and this is thread id 139796577094864.",) (Pdb) q 127.0.0.1 - - [2016-04-26 15:46:02] "POST /api/v2/auth/login HTTP/1.1" 500 181 116.978588
There was a reason that sqlite wasn't used before: django writes session objects on every request to update the expiry time, and an API that services many requests in parallel will be painfully slow waiting for sqlite commits. What was the reason for not reinstating the previous database configuration? You might still have the same issue (serving requests from inside a gevent wsgi server perhaps has something to do with the wrapper exception you're seeing), but you'd be better off starting out with a suitable backend (such as postgres) and debugging that.
For debugging your DatabaseError, try logging the thread ID during calmari_lite/server.py:main (where the db stuff is probably getting initialised in get_internal_wsgi_application, and then log the thread ID in the location where you're getting the exception, so that you can be sure of what's really going on here. Unclear why there are multiple threads in play when using the gevent wsgi server. I have no idea how pdb interacts with threads, so I'm suspicious of output from that.
Thank you for looking. postgres seems like a reasonable approach. I'll revert the commits that removed postgres and run a test to see if that gets me progress. I did take a look at pdb to debug threads and it's not up to the task as far as I can tell. If I endup in the same place after postgres it'll be either logging or gdb that I turn to.
https://github.com/ceph/calamari/tree/wip-restore-auth
QE: There is a change to the behavior of calamari-ctl initialize In 1.3 it used to interactively ask for you to create an administrator account. in 1.4 calamari-ctl initialize requires you to specify the admin account in commandline args to calamari-ctl initialize e.g. calamari-ctl initialize --admin-username <some_name> --admin-password <some_password> --admin-email <some_email> You can also use the interface described here: http://calamari.readthedocs.io/en/latest/operations/users.html
Information shared in comment 8 should be documented.
looks good to me
Verified. https://<mon Ip>:8002 now shows a 'login' link and displays: Api Root GET /api/v2/ HTTP 403 FORBIDDEN Vary: Accept Content-Type: text/html; charset=utf-8 Allow: GET, HEAD, OPTIONS { "detail": "Authentication credentials were not provided." } Using the login link one can login and continue to use calamari APIs. Verified on: calamari-server-1.4.0-0.12.rc15.el7cp.x86_64 ceph version 10.2.1-18.el7cp
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-1755.html