How to disable fauxton interface in couchdb? I'd like to make /_utils endpoint to be treated like a normal endpoint.
There's no way to make _utils be treated like a "normal" endpoint, since all endpoints that begin with _ are never normal. But you can disable it, and then it will be at least treated like a "normal" system endpoint.
From this source, (which talks about Futon--the _utils interface before CouchDB 2.x, but the same should work), simply comment-out the _utils line in your CouchDB default.ini file.
Related
I use the Bing Spell Check in my app and I can't find information regarding non-persistent mode.
I want to make sure that this service configured to no-storage. (I know in LUIS there is some flag I need to enable so I assume this is also the case but I can't find the flag)
How to make sure no data regarding the text I send is being saved?
Just to be clear there is a difference in non-persistent and non-logging data modes (the first term is not in context of the http mode). The first one is for non-personalized responses - logging may/may not happen - and the second one is no logging altogether.
LUIS supports no-logging (with log=off) mode. Bing spell check, for now, seems to support non-persistent mode only, which is also the default mode. If query doesn't contain ClientID, User-agent, ClientIP, or SessionID (all optional parameters), there is no way to trace back to particular user/browser/IP/session.
I'm developing a mobile app using PouchDB (client-side) and CouchDB (server-side).
I need to secure docs in order to allow users to read/write his own documents only.
I did a filter for this, something like:
function(doc, req) {
return doc.owner == req.userCtx.name || doc.sharedWith == req.userCtx.name;
}
and it works well, but only if the request from client includes the filter:
/somedatabase/_alldocs?filter=filter/secure
I need CouchDB to use the filter in every request, with or without client explicitation, for obvious security reasons. Is this even possible? Otherwise which is the correct approch to handle these security issues?
There is a similar question here but the answer is not applicable in my case since I need to share docs between users and replicate them between all databases is not a valid option.
So I don't know if you have looked at this wiki but it lists few options available. Some of them are outdated tho.
Per user database
Probably the most popular solution. As you said, you need to share documents with other users. This could be done by :
Copy document to other users when sharing. You could have a deamon that listen to _changes feed and update the author file in other users database.
Build a web service to access shared documents (very similar to proxy solution)
Smart Proxy
Build a smart proxy in front of your database and do some business logic to fetch the documents. This gives you more control on your data flow but it will surely be slower.
Note
The validate_doc_read server function could interest you but it has never been part of CouchDB's releases(due to the listed limitations).
Uhm, probably it isn't. The app that we are developing need to share documents with different users. any doc could be shared with a different group of users
Do you know how to change the response header in CouchDB? Now it has Cache-control: must-revalidate; and I want to change it to no-cache.
I do not see any way to configure CouchDB's cache header behavior in its configuration documentation for general (built-in) API calls. Since this is not a typical need, lack of configuration for this does not surprise me.
Likewise, last I tried even show and list functions (which do give custom developer-provided functions some control over headers) do not really leave the cache headers under developer control either.
However, if you are hosting your CouchDB instance behind a reverse proxy like nginx, you could probably override the headers at that level. Another option would be to add the usual "cache busting" hack of adding a random query parameter in the code accessing your server. This is sometimes necessary in the case of broken client cache implementations but is not typical.
But taking a step back: why do you want to make responses no-cache instead of must-revalidate? I could see perhaps occasionally wanting to override in the other direction, letting clients cache documents for a little while without having to revalidate. Not letting clients cache at all seems a little curious to me, since the built-in CouchDB behavior using revalidated Etags should not yield any incorrect data unless the client is broken.
I'm bundling a Chrome extension along with a software.
During the installation I'm creating a User ID and writing it in the registry.
I want my extension to "know" this value too, Can I do it without NPAPI plugin?
If you have a web-site for your product, you can do the following. During installation submit new UserID to your site (in addition to writing it into the Registry), then open in Chrome a specific page on your site, which should contain the same UserID in parameters. Your extansion can read outgoing requests, so it can parse out the UserID. Next it should check response from your server, which must compare UserID value obtained from the browser and the one obtained earlier from your installation. This will prevent UserID spoofing.
Also, though I'm not sure you'll not consider next suggestion as an overkill (so NPAPI plugin looks like acceptable solution as well), but here is how I made a binding between a Chrome extension and external program (for some much more sophisticated purposes than just reading the Registry).
You can build a minimal local web-server (or websockets server) processing requests on a dedicated port, provide it with registration information (UserID, etc), and then request required data from the extension just by means of ordinary http-request (for example, AJAX, or websockets client).
The methods have a drawback related to the need to setup user's firewall, so it would allow traffic either from your installer, or from local web-server.
I need to call a Kohana action through cron. I can use this code to limit only to the server IP:
$allowedIps = array('127.0.0.1','::1');
if(in_array($_SERVER['REMOTE_ADDR'],$allowedIps))
Do I need CSRF prevention, like tokens? The server is a Parallel's VPS. I wouldn't think there would be any users on a network browsing other pages making them susceptible to CSRF.
The only way I can think of preventing this, if needed, is to create a non-accessible PHP script outside of Kohana called by cron, generate a token and save to flat file, and pass that token to Kohana via an outside include using this
http://forum.kohanaframework.org/discussion/1255/load-kohana-from-external-scriptapp/p1
If the script is going to be called via the local machine (which it is according to your code sample) then you could simplify that by making sure the code is called via the CLI.
if (Kohana::$is_cli)
{
// Run function
}
As for CSRF tokens, you don't need them for this. CSRF works by exploiting someone to click a link which initiates an action on their behalf. Since you can't access the cron controller/action via a browser (you shouldn't be able to) you don't need to worry about it.
I'm pretty sure you want to use this module for any CLI-related tasks. It'll probably be included as official Kohana module since 3.3 version as it's very popular and supported.