Verify requests via server

[zzph]

Hi all,

hoping for some direction. I may be missing some fundamental understanding.

I want to 'verify' and do 'actions' depending on the couchdb requests (such as insert/update etc)

AFAIK, this is currently all done on the frontend (ie not secure).

Adding members to “_design”, such as “validate_doc_update”, is really suitable as it may need to make external calls etc.

I proxied the couchdb URL, but could not find anything meaningful in the body if the requests.

Is it possible to have a "middleware" layer (server) which allows/denies requests?

Thanks

[nickva]

_update handlers and validate_doc_update functions are one way to do it. https://docs.couchdb.org/en/stable/ddocs/ddocs.html?highlight=update%20handler#update-functions

Otherwise it seems better to handle validations and document type constraints in your application logic.

[zzph]

Thanks.

Handlers aren’t really suited as they need to be advanced/make calls to other services etc.

I saw “couchdb-nano” has listeners (“changesReader”) but they only emit AFTER the request has actioned.

How can I handle constraints in a server application before things are written to CouchDB?

[nickva]

Handlers aren’t really suited as they need to be advanced/make calls to other services etc.

That's true, there is nothing in CouchDB to make calls to other services in a updater handler or validate_doc_update function.

It seems your application layer should do the validation, run action before the updates, do the doc update, then possibly run actions after the update.

[zzph]

Could you explain how my application layer would do this?

My basic understanding says my application could:

1. route requests destined for couchDB
2. read the body (?)
3. check it all looks ok/do actions
4. pass verified requests to couchDB

Problem is- the “body” of the couchDB requests seems to have nothing in them/and there’s many of them. Is there some way I can better “read” the request before it goes to couchDB?

[nickva]

Problem is- the “body” of the couchDB requests seems to have nothing in them/and there’s many of them. Is there some way I can better “read” the request before it goes to couchDB?

If the body of the requests have nothing in them, what you base your constraints / validation on?

Otherwise, it seems you need to make external calls before the documents are written (not sure if I misunderstood that point?), so you'd build an API to handle your updates in your middleware, validate there, possibly calling pre-update handlers, then write the document to the database, then maybe run some post-update handlers.

If there is just a simple accept / reject logic, and you don't want to run a middleware layer, can use validate_doc_update function. When those reject document updates they caller will get a 403 forbidden response.