CouchDB
  1. CouchDB
  2. COUCHDB-1089

Let anonymous users access _active_tasks for view generation estimates

    Details

    • Skill Level:
      Regular Contributors Level (Easy to Medium)

      Description

      Currently you have to be a database administrator to access _active_tasks. For UX purposes I would like to allow anyone to see view generation statuses, preferably on a per database level. This solves the problem of the first user to generate a view that then receives no time estimate as to when their process will be completed. I can't think of an application use case for making replication data public.

      I spoke with Volker Mische about the implementation details on this issue and he asserted after a code dive that it appears achievable, though the innards of the view status code were not familiar to him.

        Activity

        Hide
        Caolan McMahon added a comment -

        I've wanted to have access to replication info on a per-database level before. It would be useful for creating a nicer UI for managing replication.

        Show
        Caolan McMahon added a comment - I've wanted to have access to replication info on a per-database level before. It would be useful for creating a nicer UI for managing replication.
        Hide
        Dale Harvey added a comment -

        I have also really wanted this

        I found it extremely strange that instantiating a replication was possible without admin credentials but its never possible to see its status, im happy to provide a patch if the feature is agreeable

        Show
        Dale Harvey added a comment - I have also really wanted this I found it extremely strange that instantiating a replication was possible without admin credentials but its never possible to see its status, im happy to provide a patch if the feature is agreeable
        Hide
        kowsik added a comment -

        Bad idea. I've got a bunch of Couch's on EC2 and do not want anyone to access anything on these Couch's. I have the require_valid_user set to true with the assumption that everything's locked down. While EC2 security groups help, I'll sleep better knowing that Couch is not going to reveal anything to anyone without the required credentials.

        Show
        kowsik added a comment - Bad idea. I've got a bunch of Couch's on EC2 and do not want anyone to access anything on these Couch's. I have the require_valid_user set to true with the assumption that everything's locked down. While EC2 security groups help, I'll sleep better knowing that Couch is not going to reveal anything to anyone without the required credentials.
        Hide
        Caolan McMahon added a comment -

        @Dale: if you find support for that patch I'd also consider exposing the filter and its parameters if a filter is used for replication. It could open up some really nice UI possiblities. Providing these details could make setting up custom sync with couchapps a user rather than an admin thing.

        Also, if we decide to expose _active_tasks on a per-database level it would make sense to expose it at the root level under a vhost (much like /_session).

        Show
        Caolan McMahon added a comment - @Dale: if you find support for that patch I'd also consider exposing the filter and its parameters if a filter is used for replication. It could open up some really nice UI possiblities. Providing these details could make setting up custom sync with couchapps a user rather than an admin thing. Also, if we decide to expose _active_tasks on a per-database level it would make sense to expose it at the root level under a vhost (much like /_session).
        Hide
        Filipe Manana added a comment -

        I don't think you'll need to expose the filter and parameters for a replication anywhere. That is available in the replication documents that are stored in the replicator database (version 1.1 and onwards), just read the document and you get those fields in it. Also, being like a regular database, you can set its _security object to whatever fits your application.
        As for the UI, isn't the standard Futon database page enough?

        Show
        Filipe Manana added a comment - I don't think you'll need to expose the filter and parameters for a replication anywhere. That is available in the replication documents that are stored in the replicator database (version 1.1 and onwards), just read the document and you get those fields in it. Also, being like a regular database, you can set its _security object to whatever fits your application. As for the UI, isn't the standard Futon database page enough?
        Hide
        Dale Harvey added a comment -

        Caolan, do you mean expose the filter options on the (remote) target db that you are replicating too? I can see where that can be handy but I do think it sounds dangerous.

        Kowsik, if require_valid_user does what I think it does then it wont be affected, a private install will stay private.

        Filipe, the futon replication page is ok enough as a db admins tool, we are talking about providing a ui to replication for end users of applications built with couch (more specifically in my case, couchapps), right now its impossible for me to have continuous replication for my mobile apps because the user the app runs as is not an admin, I can start continous replication tasks but cant inspect whether they are running or not.

        Show
        Dale Harvey added a comment - Caolan, do you mean expose the filter options on the (remote) target db that you are replicating too? I can see where that can be handy but I do think it sounds dangerous. Kowsik, if require_valid_user does what I think it does then it wont be affected, a private install will stay private. Filipe, the futon replication page is ok enough as a db admins tool, we are talking about providing a ui to replication for end users of applications built with couch (more specifically in my case, couchapps), right now its impossible for me to have continuous replication for my mobile apps because the user the app runs as is not an admin, I can start continous replication tasks but cant inspect whether they are running or not.
        Hide
        Filipe Manana added a comment -

        Dale, I understand that. What I'm saying is that it seems useless, since with replicator database you can know if the replication is running or not by simply reading the "_replication_state" field of the replication document. Plus, for many other use cases, you can define map/reduce views for other not so trivial things.

        Show
        Filipe Manana added a comment - Dale, I understand that. What I'm saying is that it seems useless, since with replicator database you can know if the replication is running or not by simply reading the "_replication_state" field of the replication document. Plus, for many other use cases, you can define map/reduce views for other not so trivial things.
        Hide
        Caolan McMahon added a comment -

        Only if you have 'safe rewrites' turned off or you're not behind a vhost. Getting the replication information related to a single database at a URL accessible from the db level (rather than the root level) would still be useful. Also, do all replications create an entry in the _replicator database?

        Dale, yes I have no idea if this is a good idea for security or not. Certainly needs thinking about.

        Show
        Caolan McMahon added a comment - Only if you have 'safe rewrites' turned off or you're not behind a vhost. Getting the replication information related to a single database at a URL accessible from the db level (rather than the root level) would still be useful. Also, do all replications create an entry in the _replicator database? Dale, yes I have no idea if this is a good idea for security or not. Certainly needs thinking about.

          People

          • Assignee:
            Unassigned
            Reporter:
            max ogden
          • Votes:
            2 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 3h
              3h
              Remaining:
              Remaining Estimate - 3h
              3h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development