Added implementation of ApiKeyRepository (ComponentRepository based) repository containing API keys. This way we can easly manage our API keys using adhoc commands for ComponentRepository management.

By default REST API is open and not protected if no key is available in repository (same as it was before adding API keys).

If at least one key is added then it is possible to execute REST commands only when api-key parameter is passed and contains a valid API key.

For each key we can set set of regular expression for which this API key will be valid, so we can have different keys for publicly available part of API and other API key for private API part.

We can also set list of API keys using --api-keys parameter in etc/init.properties

From the description, it looks like it is completed yet.

However, because we put more functions which are critical and can potentially contain confidential information, maybe we should make the API key based request a default mode, instead of optional. Maybe during installation, the installer should generate some random API key, or maybe the API key should be the first question Tigase asks for when run in installer mode.

I disagree. Right now on single server we may have more then one "HTTP module" - which handles particular requests. As example we have module for:

1. web based DNS resolution for web based clients

2. REST API module for handling REST requests using HTTP API handlers

It would be almost fine to secure whole access to REST API using API key, but I assume than there may be commands that should not be secured (ie. avatar retrieval as image - would be useful for users having their own web pages).

Moreover we now can set API keys for whole HTTP API component instance, while I think it should be REST API module related, so we could have 3 or more separated REST modules, all containing diffrent commands (more or less important) and each of them should have separate API key.

That's why I assume we need more precise checking in API keys and that's why I think this is not completed yet. But I would aggree that API key generation should be suggested during installation but I would still keep possibility to allow API key not being set.

Andrzej, we do not have disagreement on this. I fully agree with all that you said. What I only meant is that we should change from all open by default to all restricted by default.

Of course, we can have separate keys for different parts and modules, I have no problem with this, just opposite, I like it.

And, yes, if there is an option during installation, and user can decide whether to open HTTP/REST APIs or restrict them with key, than this is preferred way. I imagine we could have a HTML page listing all API keys configured so the user does not have to look in DB to get the key for your external application. But access to this page should be definitely restricted.

Yes, this is what I had in mind.

Settings page with API keys would be great thing to have and it could be part of Server Management console.

I separated API keys so now each module may have separate list of API keys to authorize access.

Also I changed default access model to deny any access if API key is not passed. To allow access to anyone open_access will need to be passed as value for api-keys property for module in config file or as a value for --api-keys property to open access to anyone for any module.

--api-keys property will still be used but will define default API keys for every module but api-key property passed for module will overrride this values.