couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Keen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-2390) Fauxton config, admin sections considered dangerous in 2.0
Date Mon, 24 Nov 2014 21:52:12 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223586#comment-14223586
] 

Ben Keen commented on COUCHDB-2390:
-----------------------------------

How about something like this. It’s fussy, but I think it’s better than removing the config
+ admin sections altogether. And it will at least allow the config page to function properly
in both a cluster and non-cluster setup.

On the config page, detect the couchdb version.

*1.x*
Continue showing it just like now. No problemo.

*2.x*
Case 1: If CORS *isn’t* enabled on one or more more of the nodes in the cluster, add a message
at the top of the screen saying:

{quote}
One or more of the nodes in your cluster doesn’t have CORS enabled. If you want to update
any of the config settings below you will need to manually make the change to each node. Here
are the list of nodes on your cluster:

	node1 (CORS enabled)
	node2 (CORS not enabled)
	node3 (CORS not enabled)

If you enable CORS on all servers you can update all node configs with a single action. Learn
more.”
{quote}

- All the nodes would be links to the config page on that node.
- The "Here's how to do it" could maybe open up a modal. Whatever. Something to explain what
the heck’s going on and how they can solve it.
- We can use the new /_membership endpoint to get the list of nodes in the cluster. Finding
out if they have CORS enabled should be as simple a matter as doing a GET request to them
from the client, e.g. the _config endpoint (no?).

Case 1: If CORS *is* enabled for all nodes in the cluster, add a message saying: 

	- “You are on a cluster. The changes you make here will be applied to all node config files.”

Then when a user deletes/adds a new config option, behind the scenes do *multiple* POST/DELETES
to all nodes. Only if all N succeed do you show a success message [be nice to have rollback
on any errors here, too].

I think the same logic/blurb can be used work for the Create Admin pages. 


> Fauxton config, admin sections considered dangerous in 2.0
> ----------------------------------------------------------
>
>                 Key: COUCHDB-2390
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2390
>             Project: CouchDB
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: BigCouch, Fauxton
>            Reporter: Joan Touzet
>            Priority: Blocker
>
> In Fauxton today, there is are 2 sections to edit config-file settings and to create
new admins. Neither of these sections will work as intended in a clustered setup.
> Any Fauxton session will necessarily be speaking to a single machine. The config APIs
and admin user info as exposed will only add that information to a single node's .ini file.
> We should hide these features in Fauxton for now (short-term fix) and correct the config
/admin creation APIs to work correctly in a clustered setup (medium-term fix).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message