Your comments

Is this the same as #152 (rotate secret database encryption key) ?

Actually, it would be good to have the ability to restrict ANY account to a set of IP ranges.  This would allow, for example, a read-only service account to be created for a specific integration that can only log in from a specific IP.

This is even worse when using the API to create a new item, since in this case, the item name and password are part of the URL and likely to get logged by web servers, proxies, and the like!

It appears this has now been done (at least, its in the documentation).  However there is no way to *delete* an attachment via the API, so if you want to update one (eg, remove the old private key and add a new one) then it seems it is not possible?

The GET /read/item or /find/item API calls should return an optional additional field per item, "attachments", with an array of hashes holding file IDs and names (and maybe sizes too).


Then a separate call, GET /read/attachment/<itemid>/<fileid> could return the attached file, with the correct MIME type etc.


For writing attachments, use POST /add/attachment/<item>/<name> and include the MIME type and encoded file as the post body.


For deleting, just GET /delete/attachment/<itemid>/<fileid>

Another variant on this, would be to have the option to search a folder and every folder below it. Currently you need to know the actual folder numbers for all folders.


You could also take a missing pattern to mean 'all', a zero folder to mean 'all', and allow a name for the folder (in which case it would be searched for)


e.g.

/find/item/1;2;3/foo?apikey=X  : find all items containing 'foo' under folder 1, 2 or 3

/find/item/0/foo?apikey=X : find all items containing 'foo' in any folder

/find/item/3/foo/recurse?apikey=X : find all items contiaing 'foo' in folder 3 or any folder under it

/find/item/bar/foo?apikey=X : find all items containing 'foo' in the folder with name 'bar'

/find/item/1?apikey=X : find all items in folder 1

This looks like a requirement to define Role access at a field level rather than item/folder level?

You could store them in text files, then attach the text file to the item?  This doesn't work with the API yet though

Couldn't you achieve this by having 2 separate folders, with roles appropriate to each, and then having 2 items, one in each folder, each holding half of the password?