couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lance Carlson <lancecarl...@gmail.com>
Subject Re: Curiosity how you use CouchDB in your web env.
Date Thu, 07 Mar 2013 15:20:37 GMT
Dale,

I'm A bit confused. You gave up on couchapps but still serve requests
directly to couch?

Sent from my iPhone

On Mar 7, 2013, at 10:17 AM, David Rose <doppler@gmail.com> wrote:

> Dale! Get in touch when you get here. 1 512 769 1392.
>
>
> On Wed, Mar 6, 2013 at 4:17 PM, Dale Harvey <dale@arandomurl.com> wrote:
>
>> After a long time trying to bend CouchApps into what I wanted it do it, I
>> have eventually given up and now pretty much all my applications are
>> webapps served from a plain webserver and talk to either couch directly or
>> via some application logic written node
>>
>> Also I will be at SXSW picking up my badge next week, so see you there :)
>>
>> On 6 March 2013 22:59, David Rose <doppler@gmail.com> wrote:
>>
>>> My most recent app, which we're using at SXSW for badge pickup, is a pure
>>> CouchApp. If you're at SXSW, try and find me and I'll show it to you. Or,
>>> look over the counter when you come pick up your badge.
>>>
>>> -David Rose
>>> SXSW
>>>
>>>
>>> On Wed, Mar 6, 2013 at 3:37 PM, svilen <az@svilendobrev.com> wrote:
>>>
>>>> i'm trying to use couchdb as user-facing storage, message
>>>> transport, as well as authentication. All changes=signals are handled
>>>> via secondary pub-sub-dispatcher in python (somewhat like syncpoint).
>>>> Clients replicate and talk to their own copies mostly.
>>>> Still no escape from extra webapp/python layer - to click on the link
>>>> in the confirmation email, accounts and all that webapp. Mostly
>>>> achieving same fuctionality being triggered both via http as well
>>>> as document-changes. i'm staying away from js although i do generate
>> the
>>>> js, java, objC, .. for models or view map/reduce funcs. Haven't put
>>>> any thought on further scaling or wrapping. or validation of
>>>> FiniteStateMachines that the app has turned into. or.. Maintenance.
>>>>
>>>> Though i'm quite stretched... as authentication is not
>>>> well exampled, does not easy fit the
>>>> multiple-changeable-keysets-per-user reality, and only plain
>>>> usr/psw is 100% supported in mobile touchdb replications.
>>>>
>>>> but ce-la-vie. will invent something..
>>>>
>>>> svil
>>>> www.svilendobrev.com/rabota/
>>>>
>>>> On Wed, 6 Mar 2013 15:20:29 -0500
>>>> Simon de boer <sdeboer@ingamer.com> wrote:
>>>>
>>>>> It would be great to take out the application layer, but the need for
>>>>> more Authorization controls in a relatively straight forward manner
>>>>> would be key to having this work.
>>>>>
>>>>> There are many use cases where data for one user should be completely
>>>>> impossible to access by another user.  And the more complex case of
>>>>> some data being conditionally private, ex. my friends can see my
>> email
>>>>> address, but it is private for all other users.
>>>>>
>>>>> Not only do these sort of inter-connections require more
>> authorization
>>>>> capability, but might require extreme engineering in order to wedge
>>>>> them into the CouchDB paradigm.
>>>>>
>>>>> The other option is that some requests go direct to CouchDB, as in
>> the
>>>>> public items, but other items go through the application.  Which is
>>>>> entirely viable, but you would be have be working at such a scale to
>>>>> make the overhead of maintaining this setup worthwhile.
>>>>>
>>>>> FWIW: I use a heavy Javascript client, Rails (Apache + Passenger),
>>>>> MemCache, with data migrating on a feature by feature basis from
>> MySQL
>>>>> and to CouchDB.    The eventual plan is to move to a much thinner
>>>>> Application Server with data backed by Redis and CouchDB.
>>>>>
>>>>> On Wed, Mar 6, 2013 at 3:05 PM, Sean Copenhaver
>>>>> <sean.copenhaver@gmail.com> wrote:
>>>>>> I've made a site that was only a couchapp and enjoyed the
>>>>>> experience quite a bit. I've also used it for internal tooling to
>>>>>> store data and to host mini couchapps for search or utility pages.
>>>>>>
>>>>>> In all cases though security of data (at least I didn't care who
>>>>>> could read the data)  was not a requirement and I've greatly
>>>>>> enjoyed my experiences. I would love to play around with gardener
>>>>>> along with an OS daemon to try a tightly coupled nodejs + couchdb
>>>>>> setup. Would also love to see CouchDB hosts to offer such things
as
>>>>>> well.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 6, 2013 at 2:51 PM, Dan Santner <dansantner@me.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I think it's brilliant as just a database and no more.  So that's
>>>>>>> how I use it.  I have a similar setup to your #2.  Perhaps that
>>>>>>> just because I feel most comfortable with that type of setup.
>>>>>>> This way I don't burden couch with anything security related.
 It
>>>>>>> just eats and serves docs.  My app tier handles the access control
>>>>>>> and other tasks like email or any other services over the net
that
>>>>>>> I need to use.
>>>>>>>
>>>>>>>
>>>>>>> On Mar 6, 2013, at 1:27 PM, Wendall Cada <wendallc@83864.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> We use couchdb in two configurations.
>>>>>>>>
>>>>>>>> 1. As a couchapp serving content for basic consumption. (For
a
>>>>>>>> url
>>>>>>> shortener service)
>>>>>>>> 2. As a database on localhost behind pylons or pyramid.
>>>>>>>>
>>>>>>>> To address the security question. We've been using couchdb
for
>>>>>>>> long
>>>>>>> enough that it didn't have any security when we started using
it
>> in
>>>>>>> production (0.8). Up until recently _users was a somewhat insecure
>>>>>>> feature. It's only been with the release of 1.2.0 that _users
is
>>>>>>> handled securely.
>>>>>>>>
>>>>>>>> For our needs, couchdb still does not have robust enough
acls
>>>>>>>> for any of
>>>>>>> our applications, so for now, it needs to run behind our app
>>>>>>> servers. I see changes for this on the roadmap, but until this
>>>>>>> actually happens, couchdb will happily sit on localhost serving
>>>>>>> docs.
>>>>>>>>
>>>>>>>> I'm not sure why it isn't understood that based on it's history,
>>>>>>>> CouchDB
>>>>>>> has mostly been used as a database. I know people want it to
be an
>>>>>>> app server, but, in my opinion, that's the weakest part of the
>>>>>>> entire system.
>>>>>>>>
>>>>>>>> Wendall
>>>>>>>>
>>>>>>>> On 03/06/2013 09:51 AM, Robert Newson wrote:
>>>>>>>>> "How does everyone solve the security issue?"
>>>>>>>>>
>>>>>>>>> What security problem? Only administrators can modify
design
>>>>>>>>> documents.
>>>>>>>>>
>>>>>>>>> B.
>>>>>>>>>
>>>>>>>>> On 6 March 2013 11:38, Aurélien Bénel <aurelien.benel@utt.fr>
>>>>>>>>> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>> just out of curiosity, would like to hear how
CouchDB is
>>>>>>>>>>> being used
>>>>>>> in your web environment....
>>>>>>>>>> We have two main setups:
>>>>>>>>>> - CouchApps,
>>>>>>>>>> - REST APIs used by heavy clients (Java or Firefox
extensions)
>>>>>>>>>> and
>>>>>>> attached Web applications.
>>>>>>>>>>
>>>>>>>>>>> How does everyone solve the security issue?
>>>>>>>>>> We always use CouchDB behind a reverse proxy to add
LDAP
>>>>>>> authentication and authorization when needed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Aurélien
>>>>>>
>>>>>>
>>>>>> --
>>>>>> “The limits of language are the limits of one's world. “ - Ludwig
>>>>>> von Wittgenstein
>>>>>>
>>>>>> "Water is fluid, soft and yielding. But water will wear away rock,
>>>>>> which is rigid and cannot yield. As a rule, whatever is fluid, soft
>>>>>> and yielding will overcome whatever is rigid and hard. This is
>>>>>> another paradox: what is soft is strong." - Lao-Tzu
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Become the head coach with InGamer Sports!
>>>>> http://www.InGamer.com/
>>>>>
>>>>> Simon de Boer
>>>>> 519-400-4774
>>

Mime
View raw message