Closed christophe-lejeune closed 4 years ago
Here is a screenshot of Fauxton config in CouchDB 2.3.1 (unchanged, pulled directly from docker):
httpd.authentication_handlers
looks exactly the same as in CouchDB 1.6. Or do I miss anything?
As far as I understand, this section relates to httpd
, not to chttpd
. In my instance, httpd
(port 5986) is not the section related to the 'main' service (port 5984) but reserved to administration.
Here is the documentation : https://docs.couchdb.org/en/stable/config/http.html
What port is related to httpd
in your CouchDB 2.3.1 ? Do you see a similar configuration for chttpd
?
NB: The documentation suggests that a authentication_handlers
can be included in the chttpd
section.
That makes sense. Did you test it?
The 2.3.1 syntax is a bit different :
chttpd
replaces httpd
chttpd_auth
replaces couch_httpd_auth
Here are the sections
and options
I am currently using :
Section | Option | Value |
---|---|---|
couch_httpd_auth | proxy_use_secret | true |
secret | secretkeyforcouchdbauthtoken | |
chttpd | authentication_handlers | {chttpd_auth, cookie_authentication_handler}, {chttpd_auth, proxy_authentication_handler}, {chttpd_auth, default_authentication_handler} |
CouchDB 2.3.1 is currently running on my server with these settings. I am unsure how I can test whether these settings are effectively working.
AAAforREST is listening port 80 and forward to 1337; Cassandre little proxy is listening to 1337 port and forward to Couchdb:5984.
After having restarted everything, I can read (in AAAforREST logs) that authentication apparently works.
# node app/proxy.js
Server running port 80
authenticating username
setting cookie abcd12345
[winston] Attempt to write logs with no transports {"message":"/_session 200"}
When an incorrect password is provided, the authentication is rejected.
setting cookie null
[winston] Attempt to write logs with no transports {"message":"/_session 401"}
However, at this stage, the web interface does not give access (yet) to the user. I can not say, if this comes from (1) CouchDB settings or (2) AAAforREST settings.
Indeed, AAAforREST configuration file profoundly differs from the one I was using previously.
Here is the JSON
rule used on my former installation :
"rules": [{
"control": "true",
"action": "authenticateIfPresent(context,function(){proxyWork(context)})"
}]
Here is the rule found in the JS
example config file (used on my new installation).
rules: [
{
control: function() {
return this.method != 'GET';
},
action: function() {
var $ = this;
$.authenticate($.context, function() {
$.authorize($.context, function() {
$.proxyWork($.context);
});
});
}
}
I am unsure the later express something close to the former... How would you suggest me to test my current CouchDB installation ?
Indeed, AAAforREST configuration file profoundly differs from the one I was using previously.
There are still two ways to configure AAAforREST: JS and JSON. If you are more familiar with JSON syntax, please continue to use it.
Some people prefers JS because of the ability to add comments. But I prefer JSON too.
In the code, you can find the JSON configuration used in the tests (please consult JS for related comments) : conf/config.sample.json.
There should be very few breaking changes with your old configuration. You can find them in the comments of commits added since your version.
Please note that values that are commented out in the JS are default values.
So for example, if you want to listen to port 80, you don't have to specify port
.
I am trying to switch config files, but with poor results.
With JSON
configuration, the server answers :
{"error":"not_found","reason":"missing"}
This is not very helpful.
AFAIK, the last breaking change was in version v1.2015.06.15 and was about authentication
and domain
keys on the first level. Do your config.json
has them?
{"error":"not_found","reason":"missing"} This is not very helpful.
It is:
Could you copy those paths here?
Thank you for your very prompt answer. My config file currently includes authentication
and domain
with values from the default sample file.
"authentication": {"login": "alice", "password": "whiterabbit"},
"domain": "local",
Would you advise to set different value for a production use ?
As you promptly and accurately diagnose, the problem I previously met was indeed related to rewrite rules... but not ones in CouchDB or in Cassandre's proxy. Here is what I have discovered : AAAforREST config files includes a "new" parameter (path
) that is not set in the JS sample file and set to "/cassandre/_design/cassandre/_rewrite" in the JSON sample file :
https://github.com/Hypertopic/AAAforREST/blob/master/conf/config.sample.js#L40 https://github.com/Hypertopic/AAAforREST/blob/master/conf/config.sample.json#L8
Removing this parameter from the JSON file gives good results : the user can log in (and out). This confirms it was a rewrite issue... and, perhaps, solves the whole issue ;-)
I'll have to test further to confirm everything works as expected.
By the way, as you mention earlier, the new JSON file also includes additional hostProxy's such as ^xxxcouchdb.local
and auth_http.local
. Are all theses hostProxy's useful for a production use ? Or are they intended for test only ?
Again many thanks for your help ! Have a nice evening and enjoy the week-end !
Would you advise to set different value for a production use ?
If the published credentials were the real ones, yes ^^ But SSO is not implemented by any of our applications, so risks are very low that someone could use it.
but set to "/cassandre/_design/cassandre/_rewrite" in the JSON sample file
Please consider that the JSON sample file is for testing AAAforREST not Cassandre.
Cassandre was just chosen as a sample application. Especially, the tiny proxy was not set (so please change the path
should be empty and the port
to be the same as the frontend port of the tiny proxy, which should be different from 80 since this is the port of AAAforREST).
By the way, as you mention earlier, the new JSON file also includes additional hostProxy's such as ^xxxcouchdb.local and auth_http.local. Are all theses hostProxy's useful for a production use ? Or are they intended for test only ?
They are necessary to test ALL the features of AAAforREST. They are definitely not necessary for you.
Please do a diff
between your old configuration and your new one. If something is different please ask me.
My last message means that I was probably wrong in the message before: I fear that AAAforREST talks directly to CouchDB rather than to the tiny proxy. Please check that the port in AAAforREST is not 5984 but the port of the tiny proxy.
If AAAforREST would have talked directly to CouchDB, the rewrite problem would not have occur. The "path" issue was caused by the fact that both AAAforREST and the tiny proxy were rewriting the path /cassandre/_design/cassandre/
, as you can see in the snippets, hereunder).
As mentioned in my third post ,
AAAforREST is listening port 80 and forward to 1337; Cassandre little proxy is listening to 1337 port and forward to Couchdb:5984.
Such a setting can be summarized as follows:
Service | Listens to | Forwards to |
---|---|---|
AAAforREST | 80 | 1337 |
Tiny proxy | 1337 | 5984 |
CouchDB | 5984 | / |
For documentation, here are snippets from config files :
conf/config.json
) :
"port": 80,
"authentication": {"login": "alice", "password": "whiterabbit"},
"domain": "local",
"sites": [{
"hostProxy": "cassandre.local",
"port": 1337,
"hideLocationParts": 1,
"origin": "*",
node/app.js
)
var frontend = 1337,
backend_host = '127.0.0.1',
backend_port = 5984,
backend_path = '/cassandre/_design/cassandre/';
You can see hereabove that the tiny proxy rewrites the path that AAAforREST was also rewriting during my first tests.
etc/default.ini
)
[chttpd]
port = 5984
bind_address = 0.0.0.0
For documentation, memory and help to any users wanting to perform such an installation, my notes are gathered in Cassandre's wiki.
CouchDB settings are now provided in the repository.
Three years ago, we discussed here how to configure CouchDB and AAAforREST to interact together. I have been using these settings with CouchDB 1.6 up to now. Today, it is time to move to CouchDB 2.3.
Hereunder are a few questions on how to set up such a system.
The way we configured CouchDB 1.6 is not suitable for CouchDB 2.3, namely because configuration may not be performed with such command lines.
Let's start with the following settings :
As CouchDB 1.6, CouchDB 2.3 includes a section entitled
couch_httpd_auth
. I thus suppose nothing changed concerning the first two settings. Does this assumption sounds correct to you ?CouchDB 2.3 configuration includes two different sections
chttpd
andhttpd
. Given default configuration associateschttpd
to port 5984 andhttpd
to port 5986, I guess thatauthentication_handlers
settings should be included underchttpd
. However, in the default configuration,chttpd
does not contain any optionauthentication_handlers
. Should I create such an option, or should I include this setting in another section ?