You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Markus Fischböck <m....@gmail.com> on 2016/07/12 19:54:30 UTC

System DB for Fauxton

Hi everyone!

I'm currently working on a new replicator add-on for the Fauxton UI. One
of the features I'd like to implement is a bookmark manager where a user
can create and save bookmarks in order to have them for quick access,
when selecting hosts/databases during replication. This saves the user
the hastle to remember the full URL to any source/target database he/she
want's to replicate from.

I had a discussion lately with Robert Kowalski where to store those
bookmarks and I had a couple of ideas in mind:
a) Saving the bookmarks on the local storage of the browser => this is
the least desired option, since the bookmarks would only be available on
the current browser.

b) Saving the bookmarks in the users document in the _user Database =>
Not really nice, since we would pollute the user object with data from
Fauxton. I guess it's not supposed to work that way.

c) Having a fauxton related system database (e.g. _fauxton) where we can
store UI related data. For now this would be bookmarks, but could come
in handy for other purposes like UI settings and that a like.

I wanted to ask, if it would be possible (and desireable) to add such a
system database for the Fauxton project.

Kind Regards,
Markus

Re: System DB for Fauxton

Posted by Markus Fischboeck <m....@gmail.com>.
Hi Garren,

I will definetly look into that and PouchDB sounds like a good option for
now. I think we will see on a longer term if there is any more client data
to be stored there, but from the replies to this topic it seems to be a
good idea to have a storage facility for fauxton.

Regards,
Markus

On Mon, Jul 18, 2016 at 11:20 AM, Garren Smith <ga...@apache.org> wrote:

> Hi Markus,
>
> I think the best option for now is to do it all in browser. Ideally using
> PouchDB. That way we can explore and decide what user data we want to store
> and how we want to store it. Once we have a better idea of that, we can
> then hook it up into CouchDB. Ideally if we get it right with PouchDB it
> would just be a matter of syncing between the two. Would that work for you?
>
> Cheers
> Garren
>
> On Sat, Jul 16, 2016 at 7:20 AM, Paul Davis <pa...@gmail.com>
> wrote:
>
> > Don't we already have a db-per-user plugin/feature thing? Could
> > Fauxton just not make use of that? Beyond that I'd rather not go
> > creating more "special" databases as it's already leading to some
> > rather complicated interactions with all of the various "features" we
> > have to add to make each new type behave properly.
> >
> > On Fri, Jul 15, 2016 at 11:38 PM, Markus Fischböck
> > <m....@gmail.com> wrote:
> > > I like the idea of a database per user. I thought about creating such a
> > > database by Fauxton upon login, but that won't work if the user does
> not
> > > have admin privileges, so I guess this is something that should be
> > > implemented in Couch itself.
> > > Unfortunately I can't make any contribution to this code wise, since
> I'm
> > not
> > > speaking Erlang :(
> > > I'm also not sure if this would make it into 2.0, since it seems the
> > project
> > > goes into RC phase now. So how could we proceed on that?
> > >
> > > Regards,
> > > Markus
> > >
> > >
> > >
> > >
> > > On 15.07.2016 11:23, Garren Smith wrote:
> > >>
> > >> I was speaking to Jan about this in #couchdb-dev. He makes some very
> > >> important points:
> > >>
> > >> +jan____> thing is, fauxton runs under the security context of the
> > logged
> > >> in user
> > >> 11:12 J<+jan____> so each user would need their own fauxton db
> > >> 11:12 J<+jan____> or we bleed info
> > >> 11:12 J<+jan____> or it is admin only
> > >> 11:13 J<+jan____> but then, multiple admin accounts are possible, and
> > >> they’d share it
> > >> 11:13 J<+jan____> I wonder if a browser-local PouchDB instance is the
> > >> better option
> > >>
> > >> A PouchDB instance might be better but then a user loses their info
> when
> > >> they change browsers. Otherwise Jan mentioned a db-per-user which
> could
> > >> also work really well.
> > >>
> > >> On Fri, Jul 15, 2016 at 11:03 AM, Garren Smith <ga...@apache.org>
> > wrote:
> > >>
> > >>> Markus, good points. I'm definitely +1 for the idea. Like Samuel
> says,
> > >>> storing notifications would be excellent. It would definitely allow
> us
> > to
> > >>> improve the user experience.
> > >>>
> > >>> Cheers
> > >>> Garren
> > >>>
> > >>> On Fri, Jul 15, 2016 at 8:45 AM, Samuel Kidman <sa...@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> It would be nice to store notifications in such a database. Admins
> > could
> > >>>> then see which actions have been undertaken through fauxton and by
> > whom.
> > >>>>
> > >>>> On 15 July 2016 at 06:25, Markus Fischböck <m....@gmail.com>
> > >>>> wrote:
> > >>>>
> > >>>>> Hi Garren,
> > >>>>>
> > >>>>> I guess that depends on how sensitive the data in there would be.
> > It's
> > >>>>
> > >>>> not
> > >>>>>
> > >>>>> planned to store any passwords for remote servers, so the user
> would
> > >>>>
> > >>>> need
> > >>>>>
> > >>>>> to enter those upon each replication. So in the worst case a user
> > would
> > >>>>> only see bookmarked databases on a remote server but would not be
> > able
> > >>>>
> > >>>> to
> > >>>>>
> > >>>>> access them. Given the fact that the same behavior is present on a
> > >>>>> local
> > >>>>> machine I would assume this to be OK.
> > >>>>>  From what I can tell with my limited knowledge of the internals
> it's
> > >>>>> currently not possible to secure specific documents and would
> > probably
> > >>>>> cause some interference with replication as well.
> > >>>>> So my solution would be to simply not store any sensitive there.
> > >>>>>
> > >>>>> Regards,
> > >>>>> Markus
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On 14.07.2016 12:19, Garren Smith wrote:
> > >>>>>
> > >>>>>> Hi Markus,
> > >>>>>>
> > >>>>>> I like the idea of a Fauxton system database. I think we could
> store
> > >>>>
> > >>>> some
> > >>>>>>
> > >>>>>> useful things in there. But how would we manage security and
> > >>>>
> > >>>> permissions
> > >>>>>>
> > >>>>>> on
> > >>>>>> the database?
> > >>>>>> Would one user be able to see bookmarks for another use when
> viewing
> > >>>>
> > >>>> that
> > >>>>>>
> > >>>>>> database?
> > >>>>>>
> > >>>>>> Cheers
> > >>>>>> Garren
> > >>>>>>
> > >>>>>> On Tue, Jul 12, 2016 at 9:54 PM, Markus Fischböck <
> > >>>>
> > >>>> m.fischboeck@gmail.com
> > >>>>>>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>> Hi everyone!
> > >>>>>>>
> > >>>>>>> I'm currently working on a new replicator add-on for the Fauxton
> > UI.
> > >>>>
> > >>>> One
> > >>>>>>>
> > >>>>>>> of the features I'd like to implement is a bookmark manager
> where a
> > >>>>
> > >>>> user
> > >>>>>>>
> > >>>>>>> can create and save bookmarks in order to have them for quick
> > access,
> > >>>>>>> when selecting hosts/databases during replication. This saves the
> > >>>>>>> user
> > >>>>>>> the hastle to remember the full URL to any source/target database
> > >>>>
> > >>>> he/she
> > >>>>>>>
> > >>>>>>> want's to replicate from.
> > >>>>>>>
> > >>>>>>> I had a discussion lately with Robert Kowalski where to store
> those
> > >>>>>>> bookmarks and I had a couple of ideas in mind:
> > >>>>>>> a) Saving the bookmarks on the local storage of the browser =>
> this
> > >>>>>>> is
> > >>>>>>> the least desired option, since the bookmarks would only be
> > available
> > >>>>
> > >>>> on
> > >>>>>>>
> > >>>>>>> the current browser.
> > >>>>>>>
> > >>>>>>> b) Saving the bookmarks in the users document in the _user
> Database
> > >>>>>>> =>
> > >>>>>>> Not really nice, since we would pollute the user object with data
> > >>>>>>> from
> > >>>>>>> Fauxton. I guess it's not supposed to work that way.
> > >>>>>>>
> > >>>>>>> c) Having a fauxton related system database (e.g. _fauxton) where
> > we
> > >>>>
> > >>>> can
> > >>>>>>>
> > >>>>>>> store UI related data. For now this would be bookmarks, but could
> > >>>>>>> come
> > >>>>>>> in handy for other purposes like UI settings and that a like.
> > >>>>>>>
> > >>>>>>> I wanted to ask, if it would be possible (and desireable) to add
> > such
> > >>>>
> > >>>> a
> > >>>>>>>
> > >>>>>>> system database for the Fauxton project.
> > >>>>>>>
> > >>>>>>> Kind Regards,
> > >>>>>>> Markus
> > >>>>>>>
> > >>>>>>>
> > >>>
> > >
> >
>

Re: System DB for Fauxton

Posted by Garren Smith <ga...@apache.org>.
Hi Markus,

I think the best option for now is to do it all in browser. Ideally using
PouchDB. That way we can explore and decide what user data we want to store
and how we want to store it. Once we have a better idea of that, we can
then hook it up into CouchDB. Ideally if we get it right with PouchDB it
would just be a matter of syncing between the two. Would that work for you?

Cheers
Garren

On Sat, Jul 16, 2016 at 7:20 AM, Paul Davis <pa...@gmail.com>
wrote:

> Don't we already have a db-per-user plugin/feature thing? Could
> Fauxton just not make use of that? Beyond that I'd rather not go
> creating more "special" databases as it's already leading to some
> rather complicated interactions with all of the various "features" we
> have to add to make each new type behave properly.
>
> On Fri, Jul 15, 2016 at 11:38 PM, Markus Fischböck
> <m....@gmail.com> wrote:
> > I like the idea of a database per user. I thought about creating such a
> > database by Fauxton upon login, but that won't work if the user does not
> > have admin privileges, so I guess this is something that should be
> > implemented in Couch itself.
> > Unfortunately I can't make any contribution to this code wise, since I'm
> not
> > speaking Erlang :(
> > I'm also not sure if this would make it into 2.0, since it seems the
> project
> > goes into RC phase now. So how could we proceed on that?
> >
> > Regards,
> > Markus
> >
> >
> >
> >
> > On 15.07.2016 11:23, Garren Smith wrote:
> >>
> >> I was speaking to Jan about this in #couchdb-dev. He makes some very
> >> important points:
> >>
> >> +jan____> thing is, fauxton runs under the security context of the
> logged
> >> in user
> >> 11:12 J<+jan____> so each user would need their own fauxton db
> >> 11:12 J<+jan____> or we bleed info
> >> 11:12 J<+jan____> or it is admin only
> >> 11:13 J<+jan____> but then, multiple admin accounts are possible, and
> >> they’d share it
> >> 11:13 J<+jan____> I wonder if a browser-local PouchDB instance is the
> >> better option
> >>
> >> A PouchDB instance might be better but then a user loses their info when
> >> they change browsers. Otherwise Jan mentioned a db-per-user which could
> >> also work really well.
> >>
> >> On Fri, Jul 15, 2016 at 11:03 AM, Garren Smith <ga...@apache.org>
> wrote:
> >>
> >>> Markus, good points. I'm definitely +1 for the idea. Like Samuel says,
> >>> storing notifications would be excellent. It would definitely allow us
> to
> >>> improve the user experience.
> >>>
> >>> Cheers
> >>> Garren
> >>>
> >>> On Fri, Jul 15, 2016 at 8:45 AM, Samuel Kidman <sa...@gmail.com>
> >>> wrote:
> >>>
> >>>> It would be nice to store notifications in such a database. Admins
> could
> >>>> then see which actions have been undertaken through fauxton and by
> whom.
> >>>>
> >>>> On 15 July 2016 at 06:25, Markus Fischböck <m....@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hi Garren,
> >>>>>
> >>>>> I guess that depends on how sensitive the data in there would be.
> It's
> >>>>
> >>>> not
> >>>>>
> >>>>> planned to store any passwords for remote servers, so the user would
> >>>>
> >>>> need
> >>>>>
> >>>>> to enter those upon each replication. So in the worst case a user
> would
> >>>>> only see bookmarked databases on a remote server but would not be
> able
> >>>>
> >>>> to
> >>>>>
> >>>>> access them. Given the fact that the same behavior is present on a
> >>>>> local
> >>>>> machine I would assume this to be OK.
> >>>>>  From what I can tell with my limited knowledge of the internals it's
> >>>>> currently not possible to secure specific documents and would
> probably
> >>>>> cause some interference with replication as well.
> >>>>> So my solution would be to simply not store any sensitive there.
> >>>>>
> >>>>> Regards,
> >>>>> Markus
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 14.07.2016 12:19, Garren Smith wrote:
> >>>>>
> >>>>>> Hi Markus,
> >>>>>>
> >>>>>> I like the idea of a Fauxton system database. I think we could store
> >>>>
> >>>> some
> >>>>>>
> >>>>>> useful things in there. But how would we manage security and
> >>>>
> >>>> permissions
> >>>>>>
> >>>>>> on
> >>>>>> the database?
> >>>>>> Would one user be able to see bookmarks for another use when viewing
> >>>>
> >>>> that
> >>>>>>
> >>>>>> database?
> >>>>>>
> >>>>>> Cheers
> >>>>>> Garren
> >>>>>>
> >>>>>> On Tue, Jul 12, 2016 at 9:54 PM, Markus Fischböck <
> >>>>
> >>>> m.fischboeck@gmail.com
> >>>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hi everyone!
> >>>>>>>
> >>>>>>> I'm currently working on a new replicator add-on for the Fauxton
> UI.
> >>>>
> >>>> One
> >>>>>>>
> >>>>>>> of the features I'd like to implement is a bookmark manager where a
> >>>>
> >>>> user
> >>>>>>>
> >>>>>>> can create and save bookmarks in order to have them for quick
> access,
> >>>>>>> when selecting hosts/databases during replication. This saves the
> >>>>>>> user
> >>>>>>> the hastle to remember the full URL to any source/target database
> >>>>
> >>>> he/she
> >>>>>>>
> >>>>>>> want's to replicate from.
> >>>>>>>
> >>>>>>> I had a discussion lately with Robert Kowalski where to store those
> >>>>>>> bookmarks and I had a couple of ideas in mind:
> >>>>>>> a) Saving the bookmarks on the local storage of the browser => this
> >>>>>>> is
> >>>>>>> the least desired option, since the bookmarks would only be
> available
> >>>>
> >>>> on
> >>>>>>>
> >>>>>>> the current browser.
> >>>>>>>
> >>>>>>> b) Saving the bookmarks in the users document in the _user Database
> >>>>>>> =>
> >>>>>>> Not really nice, since we would pollute the user object with data
> >>>>>>> from
> >>>>>>> Fauxton. I guess it's not supposed to work that way.
> >>>>>>>
> >>>>>>> c) Having a fauxton related system database (e.g. _fauxton) where
> we
> >>>>
> >>>> can
> >>>>>>>
> >>>>>>> store UI related data. For now this would be bookmarks, but could
> >>>>>>> come
> >>>>>>> in handy for other purposes like UI settings and that a like.
> >>>>>>>
> >>>>>>> I wanted to ask, if it would be possible (and desireable) to add
> such
> >>>>
> >>>> a
> >>>>>>>
> >>>>>>> system database for the Fauxton project.
> >>>>>>>
> >>>>>>> Kind Regards,
> >>>>>>> Markus
> >>>>>>>
> >>>>>>>
> >>>
> >
>

Re: System DB for Fauxton

Posted by Paul Davis <pa...@gmail.com>.
Don't we already have a db-per-user plugin/feature thing? Could
Fauxton just not make use of that? Beyond that I'd rather not go
creating more "special" databases as it's already leading to some
rather complicated interactions with all of the various "features" we
have to add to make each new type behave properly.

On Fri, Jul 15, 2016 at 11:38 PM, Markus Fischböck
<m....@gmail.com> wrote:
> I like the idea of a database per user. I thought about creating such a
> database by Fauxton upon login, but that won't work if the user does not
> have admin privileges, so I guess this is something that should be
> implemented in Couch itself.
> Unfortunately I can't make any contribution to this code wise, since I'm not
> speaking Erlang :(
> I'm also not sure if this would make it into 2.0, since it seems the project
> goes into RC phase now. So how could we proceed on that?
>
> Regards,
> Markus
>
>
>
>
> On 15.07.2016 11:23, Garren Smith wrote:
>>
>> I was speaking to Jan about this in #couchdb-dev. He makes some very
>> important points:
>>
>> +jan____> thing is, fauxton runs under the security context of the logged
>> in user
>> 11:12 J<+jan____> so each user would need their own fauxton db
>> 11:12 J<+jan____> or we bleed info
>> 11:12 J<+jan____> or it is admin only
>> 11:13 J<+jan____> but then, multiple admin accounts are possible, and
>> they’d share it
>> 11:13 J<+jan____> I wonder if a browser-local PouchDB instance is the
>> better option
>>
>> A PouchDB instance might be better but then a user loses their info when
>> they change browsers. Otherwise Jan mentioned a db-per-user which could
>> also work really well.
>>
>> On Fri, Jul 15, 2016 at 11:03 AM, Garren Smith <ga...@apache.org> wrote:
>>
>>> Markus, good points. I'm definitely +1 for the idea. Like Samuel says,
>>> storing notifications would be excellent. It would definitely allow us to
>>> improve the user experience.
>>>
>>> Cheers
>>> Garren
>>>
>>> On Fri, Jul 15, 2016 at 8:45 AM, Samuel Kidman <sa...@gmail.com>
>>> wrote:
>>>
>>>> It would be nice to store notifications in such a database. Admins could
>>>> then see which actions have been undertaken through fauxton and by whom.
>>>>
>>>> On 15 July 2016 at 06:25, Markus Fischböck <m....@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Garren,
>>>>>
>>>>> I guess that depends on how sensitive the data in there would be. It's
>>>>
>>>> not
>>>>>
>>>>> planned to store any passwords for remote servers, so the user would
>>>>
>>>> need
>>>>>
>>>>> to enter those upon each replication. So in the worst case a user would
>>>>> only see bookmarked databases on a remote server but would not be able
>>>>
>>>> to
>>>>>
>>>>> access them. Given the fact that the same behavior is present on a
>>>>> local
>>>>> machine I would assume this to be OK.
>>>>>  From what I can tell with my limited knowledge of the internals it's
>>>>> currently not possible to secure specific documents and would probably
>>>>> cause some interference with replication as well.
>>>>> So my solution would be to simply not store any sensitive there.
>>>>>
>>>>> Regards,
>>>>> Markus
>>>>>
>>>>>
>>>>>
>>>>> On 14.07.2016 12:19, Garren Smith wrote:
>>>>>
>>>>>> Hi Markus,
>>>>>>
>>>>>> I like the idea of a Fauxton system database. I think we could store
>>>>
>>>> some
>>>>>>
>>>>>> useful things in there. But how would we manage security and
>>>>
>>>> permissions
>>>>>>
>>>>>> on
>>>>>> the database?
>>>>>> Would one user be able to see bookmarks for another use when viewing
>>>>
>>>> that
>>>>>>
>>>>>> database?
>>>>>>
>>>>>> Cheers
>>>>>> Garren
>>>>>>
>>>>>> On Tue, Jul 12, 2016 at 9:54 PM, Markus Fischböck <
>>>>
>>>> m.fischboeck@gmail.com
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> Hi everyone!
>>>>>>>
>>>>>>> I'm currently working on a new replicator add-on for the Fauxton UI.
>>>>
>>>> One
>>>>>>>
>>>>>>> of the features I'd like to implement is a bookmark manager where a
>>>>
>>>> user
>>>>>>>
>>>>>>> can create and save bookmarks in order to have them for quick access,
>>>>>>> when selecting hosts/databases during replication. This saves the
>>>>>>> user
>>>>>>> the hastle to remember the full URL to any source/target database
>>>>
>>>> he/she
>>>>>>>
>>>>>>> want's to replicate from.
>>>>>>>
>>>>>>> I had a discussion lately with Robert Kowalski where to store those
>>>>>>> bookmarks and I had a couple of ideas in mind:
>>>>>>> a) Saving the bookmarks on the local storage of the browser => this
>>>>>>> is
>>>>>>> the least desired option, since the bookmarks would only be available
>>>>
>>>> on
>>>>>>>
>>>>>>> the current browser.
>>>>>>>
>>>>>>> b) Saving the bookmarks in the users document in the _user Database
>>>>>>> =>
>>>>>>> Not really nice, since we would pollute the user object with data
>>>>>>> from
>>>>>>> Fauxton. I guess it's not supposed to work that way.
>>>>>>>
>>>>>>> c) Having a fauxton related system database (e.g. _fauxton) where we
>>>>
>>>> can
>>>>>>>
>>>>>>> store UI related data. For now this would be bookmarks, but could
>>>>>>> come
>>>>>>> in handy for other purposes like UI settings and that a like.
>>>>>>>
>>>>>>> I wanted to ask, if it would be possible (and desireable) to add such
>>>>
>>>> a
>>>>>>>
>>>>>>> system database for the Fauxton project.
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>> Markus
>>>>>>>
>>>>>>>
>>>
>

Re: System DB for Fauxton

Posted by Markus Fischböck <m....@gmail.com>.
I like the idea of a database per user. I thought about creating such a 
database by Fauxton upon login, but that won't work if the user does not 
have admin privileges, so I guess this is something that should be 
implemented in Couch itself.
Unfortunately I can't make any contribution to this code wise, since I'm 
not speaking Erlang :(
I'm also not sure if this would make it into 2.0, since it seems the 
project goes into RC phase now. So how could we proceed on that?

Regards,
Markus



On 15.07.2016 11:23, Garren Smith wrote:
> I was speaking to Jan about this in #couchdb-dev. He makes some very
> important points:
>
> +jan____> thing is, fauxton runs under the security context of the logged
> in user
> 11:12 J<+jan____> so each user would need their own fauxton db
> 11:12 J<+jan____> or we bleed info
> 11:12 J<+jan____> or it is admin only
> 11:13 J<+jan____> but then, multiple admin accounts are possible, and
> they\u2019d share it
> 11:13 J<+jan____> I wonder if a browser-local PouchDB instance is the
> better option
>
> A PouchDB instance might be better but then a user loses their info when
> they change browsers. Otherwise Jan mentioned a db-per-user which could
> also work really well.
>
> On Fri, Jul 15, 2016 at 11:03 AM, Garren Smith <ga...@apache.org> wrote:
>
>> Markus, good points. I'm definitely +1 for the idea. Like Samuel says,
>> storing notifications would be excellent. It would definitely allow us to
>> improve the user experience.
>>
>> Cheers
>> Garren
>>
>> On Fri, Jul 15, 2016 at 8:45 AM, Samuel Kidman <sa...@gmail.com>
>> wrote:
>>
>>> It would be nice to store notifications in such a database. Admins could
>>> then see which actions have been undertaken through fauxton and by whom.
>>>
>>> On 15 July 2016 at 06:25, Markus Fischb�ck <m....@gmail.com>
>>> wrote:
>>>
>>>> Hi Garren,
>>>>
>>>> I guess that depends on how sensitive the data in there would be. It's
>>> not
>>>> planned to store any passwords for remote servers, so the user would
>>> need
>>>> to enter those upon each replication. So in the worst case a user would
>>>> only see bookmarked databases on a remote server but would not be able
>>> to
>>>> access them. Given the fact that the same behavior is present on a local
>>>> machine I would assume this to be OK.
>>>>  From what I can tell with my limited knowledge of the internals it's
>>>> currently not possible to secure specific documents and would probably
>>>> cause some interference with replication as well.
>>>> So my solution would be to simply not store any sensitive there.
>>>>
>>>> Regards,
>>>> Markus
>>>>
>>>>
>>>>
>>>> On 14.07.2016 12:19, Garren Smith wrote:
>>>>
>>>>> Hi Markus,
>>>>>
>>>>> I like the idea of a Fauxton system database. I think we could store
>>> some
>>>>> useful things in there. But how would we manage security and
>>> permissions
>>>>> on
>>>>> the database?
>>>>> Would one user be able to see bookmarks for another use when viewing
>>> that
>>>>> database?
>>>>>
>>>>> Cheers
>>>>> Garren
>>>>>
>>>>> On Tue, Jul 12, 2016 at 9:54 PM, Markus Fischb�ck <
>>> m.fischboeck@gmail.com
>>>>> wrote:
>>>>>
>>>>> Hi everyone!
>>>>>> I'm currently working on a new replicator add-on for the Fauxton UI.
>>> One
>>>>>> of the features I'd like to implement is a bookmark manager where a
>>> user
>>>>>> can create and save bookmarks in order to have them for quick access,
>>>>>> when selecting hosts/databases during replication. This saves the user
>>>>>> the hastle to remember the full URL to any source/target database
>>> he/she
>>>>>> want's to replicate from.
>>>>>>
>>>>>> I had a discussion lately with Robert Kowalski where to store those
>>>>>> bookmarks and I had a couple of ideas in mind:
>>>>>> a) Saving the bookmarks on the local storage of the browser => this is
>>>>>> the least desired option, since the bookmarks would only be available
>>> on
>>>>>> the current browser.
>>>>>>
>>>>>> b) Saving the bookmarks in the users document in the _user Database =>
>>>>>> Not really nice, since we would pollute the user object with data from
>>>>>> Fauxton. I guess it's not supposed to work that way.
>>>>>>
>>>>>> c) Having a fauxton related system database (e.g. _fauxton) where we
>>> can
>>>>>> store UI related data. For now this would be bookmarks, but could come
>>>>>> in handy for other purposes like UI settings and that a like.
>>>>>>
>>>>>> I wanted to ask, if it would be possible (and desireable) to add such
>>> a
>>>>>> system database for the Fauxton project.
>>>>>>
>>>>>> Kind Regards,
>>>>>> Markus
>>>>>>
>>>>>>
>>


Re: System DB for Fauxton

Posted by Garren Smith <ga...@apache.org>.
I was speaking to Jan about this in #couchdb-dev. He makes some very
important points:

+jan____> thing is, fauxton runs under the security context of the logged
in user
11:12 J<+jan____> so each user would need their own fauxton db
11:12 J<+jan____> or we bleed info
11:12 J<+jan____> or it is admin only
11:13 J<+jan____> but then, multiple admin accounts are possible, and
they’d share it
11:13 J<+jan____> I wonder if a browser-local PouchDB instance is the
better option

A PouchDB instance might be better but then a user loses their info when
they change browsers. Otherwise Jan mentioned a db-per-user which could
also work really well.

On Fri, Jul 15, 2016 at 11:03 AM, Garren Smith <ga...@apache.org> wrote:

> Markus, good points. I'm definitely +1 for the idea. Like Samuel says,
> storing notifications would be excellent. It would definitely allow us to
> improve the user experience.
>
> Cheers
> Garren
>
> On Fri, Jul 15, 2016 at 8:45 AM, Samuel Kidman <sa...@gmail.com>
> wrote:
>
>> It would be nice to store notifications in such a database. Admins could
>> then see which actions have been undertaken through fauxton and by whom.
>>
>> On 15 July 2016 at 06:25, Markus Fischböck <m....@gmail.com>
>> wrote:
>>
>> > Hi Garren,
>> >
>> > I guess that depends on how sensitive the data in there would be. It's
>> not
>> > planned to store any passwords for remote servers, so the user would
>> need
>> > to enter those upon each replication. So in the worst case a user would
>> > only see bookmarked databases on a remote server but would not be able
>> to
>> > access them. Given the fact that the same behavior is present on a local
>> > machine I would assume this to be OK.
>> > From what I can tell with my limited knowledge of the internals it's
>> > currently not possible to secure specific documents and would probably
>> > cause some interference with replication as well.
>> > So my solution would be to simply not store any sensitive there.
>> >
>> > Regards,
>> > Markus
>> >
>> >
>> >
>> > On 14.07.2016 12:19, Garren Smith wrote:
>> >
>> >> Hi Markus,
>> >>
>> >> I like the idea of a Fauxton system database. I think we could store
>> some
>> >> useful things in there. But how would we manage security and
>> permissions
>> >> on
>> >> the database?
>> >> Would one user be able to see bookmarks for another use when viewing
>> that
>> >> database?
>> >>
>> >> Cheers
>> >> Garren
>> >>
>> >> On Tue, Jul 12, 2016 at 9:54 PM, Markus Fischböck <
>> m.fischboeck@gmail.com
>> >> >
>> >> wrote:
>> >>
>> >> Hi everyone!
>> >>>
>> >>> I'm currently working on a new replicator add-on for the Fauxton UI.
>> One
>> >>> of the features I'd like to implement is a bookmark manager where a
>> user
>> >>> can create and save bookmarks in order to have them for quick access,
>> >>> when selecting hosts/databases during replication. This saves the user
>> >>> the hastle to remember the full URL to any source/target database
>> he/she
>> >>> want's to replicate from.
>> >>>
>> >>> I had a discussion lately with Robert Kowalski where to store those
>> >>> bookmarks and I had a couple of ideas in mind:
>> >>> a) Saving the bookmarks on the local storage of the browser => this is
>> >>> the least desired option, since the bookmarks would only be available
>> on
>> >>> the current browser.
>> >>>
>> >>> b) Saving the bookmarks in the users document in the _user Database =>
>> >>> Not really nice, since we would pollute the user object with data from
>> >>> Fauxton. I guess it's not supposed to work that way.
>> >>>
>> >>> c) Having a fauxton related system database (e.g. _fauxton) where we
>> can
>> >>> store UI related data. For now this would be bookmarks, but could come
>> >>> in handy for other purposes like UI settings and that a like.
>> >>>
>> >>> I wanted to ask, if it would be possible (and desireable) to add such
>> a
>> >>> system database for the Fauxton project.
>> >>>
>> >>> Kind Regards,
>> >>> Markus
>> >>>
>> >>>
>> >
>>
>
>

Re: System DB for Fauxton

Posted by Garren Smith <ga...@apache.org>.
Markus, good points. I'm definitely +1 for the idea. Like Samuel says,
storing notifications would be excellent. It would definitely allow us to
improve the user experience.

Cheers
Garren

On Fri, Jul 15, 2016 at 8:45 AM, Samuel Kidman <sa...@gmail.com> wrote:

> It would be nice to store notifications in such a database. Admins could
> then see which actions have been undertaken through fauxton and by whom.
>
> On 15 July 2016 at 06:25, Markus Fischböck <m....@gmail.com> wrote:
>
> > Hi Garren,
> >
> > I guess that depends on how sensitive the data in there would be. It's
> not
> > planned to store any passwords for remote servers, so the user would need
> > to enter those upon each replication. So in the worst case a user would
> > only see bookmarked databases on a remote server but would not be able to
> > access them. Given the fact that the same behavior is present on a local
> > machine I would assume this to be OK.
> > From what I can tell with my limited knowledge of the internals it's
> > currently not possible to secure specific documents and would probably
> > cause some interference with replication as well.
> > So my solution would be to simply not store any sensitive there.
> >
> > Regards,
> > Markus
> >
> >
> >
> > On 14.07.2016 12:19, Garren Smith wrote:
> >
> >> Hi Markus,
> >>
> >> I like the idea of a Fauxton system database. I think we could store
> some
> >> useful things in there. But how would we manage security and permissions
> >> on
> >> the database?
> >> Would one user be able to see bookmarks for another use when viewing
> that
> >> database?
> >>
> >> Cheers
> >> Garren
> >>
> >> On Tue, Jul 12, 2016 at 9:54 PM, Markus Fischböck <
> m.fischboeck@gmail.com
> >> >
> >> wrote:
> >>
> >> Hi everyone!
> >>>
> >>> I'm currently working on a new replicator add-on for the Fauxton UI.
> One
> >>> of the features I'd like to implement is a bookmark manager where a
> user
> >>> can create and save bookmarks in order to have them for quick access,
> >>> when selecting hosts/databases during replication. This saves the user
> >>> the hastle to remember the full URL to any source/target database
> he/she
> >>> want's to replicate from.
> >>>
> >>> I had a discussion lately with Robert Kowalski where to store those
> >>> bookmarks and I had a couple of ideas in mind:
> >>> a) Saving the bookmarks on the local storage of the browser => this is
> >>> the least desired option, since the bookmarks would only be available
> on
> >>> the current browser.
> >>>
> >>> b) Saving the bookmarks in the users document in the _user Database =>
> >>> Not really nice, since we would pollute the user object with data from
> >>> Fauxton. I guess it's not supposed to work that way.
> >>>
> >>> c) Having a fauxton related system database (e.g. _fauxton) where we
> can
> >>> store UI related data. For now this would be bookmarks, but could come
> >>> in handy for other purposes like UI settings and that a like.
> >>>
> >>> I wanted to ask, if it would be possible (and desireable) to add such a
> >>> system database for the Fauxton project.
> >>>
> >>> Kind Regards,
> >>> Markus
> >>>
> >>>
> >
>

Re: System DB for Fauxton

Posted by Samuel Kidman <sa...@gmail.com>.
It would be nice to store notifications in such a database. Admins could
then see which actions have been undertaken through fauxton and by whom.

On 15 July 2016 at 06:25, Markus Fischböck <m....@gmail.com> wrote:

> Hi Garren,
>
> I guess that depends on how sensitive the data in there would be. It's not
> planned to store any passwords for remote servers, so the user would need
> to enter those upon each replication. So in the worst case a user would
> only see bookmarked databases on a remote server but would not be able to
> access them. Given the fact that the same behavior is present on a local
> machine I would assume this to be OK.
> From what I can tell with my limited knowledge of the internals it's
> currently not possible to secure specific documents and would probably
> cause some interference with replication as well.
> So my solution would be to simply not store any sensitive there.
>
> Regards,
> Markus
>
>
>
> On 14.07.2016 12:19, Garren Smith wrote:
>
>> Hi Markus,
>>
>> I like the idea of a Fauxton system database. I think we could store some
>> useful things in there. But how would we manage security and permissions
>> on
>> the database?
>> Would one user be able to see bookmarks for another use when viewing that
>> database?
>>
>> Cheers
>> Garren
>>
>> On Tue, Jul 12, 2016 at 9:54 PM, Markus Fischböck <m.fischboeck@gmail.com
>> >
>> wrote:
>>
>> Hi everyone!
>>>
>>> I'm currently working on a new replicator add-on for the Fauxton UI. One
>>> of the features I'd like to implement is a bookmark manager where a user
>>> can create and save bookmarks in order to have them for quick access,
>>> when selecting hosts/databases during replication. This saves the user
>>> the hastle to remember the full URL to any source/target database he/she
>>> want's to replicate from.
>>>
>>> I had a discussion lately with Robert Kowalski where to store those
>>> bookmarks and I had a couple of ideas in mind:
>>> a) Saving the bookmarks on the local storage of the browser => this is
>>> the least desired option, since the bookmarks would only be available on
>>> the current browser.
>>>
>>> b) Saving the bookmarks in the users document in the _user Database =>
>>> Not really nice, since we would pollute the user object with data from
>>> Fauxton. I guess it's not supposed to work that way.
>>>
>>> c) Having a fauxton related system database (e.g. _fauxton) where we can
>>> store UI related data. For now this would be bookmarks, but could come
>>> in handy for other purposes like UI settings and that a like.
>>>
>>> I wanted to ask, if it would be possible (and desireable) to add such a
>>> system database for the Fauxton project.
>>>
>>> Kind Regards,
>>> Markus
>>>
>>>
>

Re: System DB for Fauxton

Posted by Markus Fischböck <m....@gmail.com>.
Hi Garren,

I guess that depends on how sensitive the data in there would be. It's 
not planned to store any passwords for remote servers, so the user would 
need to enter those upon each replication. So in the worst case a user 
would only see bookmarked databases on a remote server but would not be 
able to access them. Given the fact that the same behavior is present on 
a local machine I would assume this to be OK.
 From what I can tell with my limited knowledge of the internals it's 
currently not possible to secure specific documents and would probably 
cause some interference with replication as well.
So my solution would be to simply not store any sensitive there.

Regards,
Markus


On 14.07.2016 12:19, Garren Smith wrote:
> Hi Markus,
>
> I like the idea of a Fauxton system database. I think we could store some
> useful things in there. But how would we manage security and permissions on
> the database?
> Would one user be able to see bookmarks for another use when viewing that
> database?
>
> Cheers
> Garren
>
> On Tue, Jul 12, 2016 at 9:54 PM, Markus Fischb�ck <m....@gmail.com>
> wrote:
>
>> Hi everyone!
>>
>> I'm currently working on a new replicator add-on for the Fauxton UI. One
>> of the features I'd like to implement is a bookmark manager where a user
>> can create and save bookmarks in order to have them for quick access,
>> when selecting hosts/databases during replication. This saves the user
>> the hastle to remember the full URL to any source/target database he/she
>> want's to replicate from.
>>
>> I had a discussion lately with Robert Kowalski where to store those
>> bookmarks and I had a couple of ideas in mind:
>> a) Saving the bookmarks on the local storage of the browser => this is
>> the least desired option, since the bookmarks would only be available on
>> the current browser.
>>
>> b) Saving the bookmarks in the users document in the _user Database =>
>> Not really nice, since we would pollute the user object with data from
>> Fauxton. I guess it's not supposed to work that way.
>>
>> c) Having a fauxton related system database (e.g. _fauxton) where we can
>> store UI related data. For now this would be bookmarks, but could come
>> in handy for other purposes like UI settings and that a like.
>>
>> I wanted to ask, if it would be possible (and desireable) to add such a
>> system database for the Fauxton project.
>>
>> Kind Regards,
>> Markus
>>


Re: System DB for Fauxton

Posted by Garren Smith <ga...@apache.org>.
Hi Markus,

I like the idea of a Fauxton system database. I think we could store some
useful things in there. But how would we manage security and permissions on
the database?
Would one user be able to see bookmarks for another use when viewing that
database?

Cheers
Garren

On Tue, Jul 12, 2016 at 9:54 PM, Markus Fischböck <m....@gmail.com>
wrote:

> Hi everyone!
>
> I'm currently working on a new replicator add-on for the Fauxton UI. One
> of the features I'd like to implement is a bookmark manager where a user
> can create and save bookmarks in order to have them for quick access,
> when selecting hosts/databases during replication. This saves the user
> the hastle to remember the full URL to any source/target database he/she
> want's to replicate from.
>
> I had a discussion lately with Robert Kowalski where to store those
> bookmarks and I had a couple of ideas in mind:
> a) Saving the bookmarks on the local storage of the browser => this is
> the least desired option, since the bookmarks would only be available on
> the current browser.
>
> b) Saving the bookmarks in the users document in the _user Database =>
> Not really nice, since we would pollute the user object with data from
> Fauxton. I guess it's not supposed to work that way.
>
> c) Having a fauxton related system database (e.g. _fauxton) where we can
> store UI related data. For now this would be bookmarks, but could come
> in handy for other purposes like UI settings and that a like.
>
> I wanted to ask, if it would be possible (and desireable) to add such a
> system database for the Fauxton project.
>
> Kind Regards,
> Markus
>