Split configuration file into two: server and client config files

[psolom]

Here the original message from @jlaustill
I have examinated the json config file and found that many of options are client-side or server-side related solely. Of course, it's convenient to keep all configuration in one place and all of the options are utilized in FM + PHP connector. But let's consider few options:

1. it's an ordinary situation when some connector may not implement all of server-side options which are implemented in PHP connector for some reason. It may bring a confusion for user, because he expects that all listed options affect FM.

2. as noted @jlaustill: As it is, with the api and ui on seperate servers, it looks like I'll have to do an ajax request back to origin to grab the config file for every single request. This isn't great, it opens up to spoofing attacks.

3. PHP connector entry script allows to pass extra config options to the constructor in order to override options from json config. It's convenient, but leads to another confusion, because it will work for server-side options only. The client-side have been already initiated with options from the config file at this point.

Here is the server-side config file for PHP connector. It's easy for me to move server-ralated options to this file. On the other hand there are some options in config file which are used in both sides. For instance options.lang, options.capabilities, some of security, upload, images sections, etc.

So we will get some options duplicated in both configuration files. It's more difficult to manage, but also more secure and less confusing (see p.2 and p.3), user can be sure that an option will take effect if he changes it. I believe it's the better option.

@jlaustill, @gmkll, @fabriceci, @simogeo
Looking forward to your notes.

[jlaustill]

I would just like to note that for now there will be some options duplicated, but in the future it would be a good idea to make those server/api side options, and have the ui ask for the settings when it initializes. One example is security, this should be server side for security reasons, and the ui should ask the api hey, what are your rules? I would recommend a mode=init that simply returns the proper settings, minus the ones the ui shouldn't have.

I think that will become much more clear once we work on it and start to get this all flushed out. When I get to work today I'll pull your latest changes and start working through the nodejs connector one call at a time and updating everything in the wiki.

[gmkll]

+1 security, upload, allowed file types on server side definitely.

The client COULD evaluate it´s own properties, as the server does, but they should be independent, as merging is difficult and error prone. The inherent logic then is, the client does use it´s UI setting and if it has server-related settings, they are used just for pre-filtering. The server side COULD decide to be more restrictive, on it´s own measures then, of course.

No merging from remote required then on either side. As in PHP-Conn the server COULD read client configurations and merge it with it´s server side conf, but this is an advanced feature and it may be better to do this kind of opt-in, as it is dangerous to have client side dependencies on the server side.

[psolom]

I have started on that config file dividing. And that is how I'm going to do it:

• connector has it's own independent config file at the server-side.
• frontent has it's own independent config file in the "scripts" folder (as it's now)

Then @jlaustill gave a good idea to have init request in API. It could be used to retrieve some config options from the connector's config file to override them in the frontend's config file. This will solve this issue. For that pursose init method in a connector should describe a list of "safe" options in its config file to be returned in the response, in order to override ones in frontend's config file. With that point we don't need to duplicate config options which are common for both server and client sides, just to return them in init response.

So here we come to the last points:

• connector config settings are NOT able to be overwritten by frontend's config file (no conjuction)
• frontent config settings are able to be overwritten by connector's config file (via init request)

That's a basic idea.

[fabriceci]

About the divisions problems.

I would keep the same config (like now) on the client side without the API and SECURITY object. On the init function, the server will be able to overload all parameters, the only one required is the API object. (easy to handle)

In this way, the connector would be able to change the fm beviahour on the fly, for example, limit capabilities according the user roles :)

For the param like regex, you can divide in two parameters in the server config, the server side param will be ignored by the fm (eg : ClientSideRegex/ServerSIdeRegex).

What do you think?

[psolom]

API is the client-side section exclusively.
It determines which connector to use and the URL to connector if needed.
So it will stay in json file definetely.

And if a connector will be able to overload parameters on some "init" request then we can leave SECURITY section as well. I vote to leave all sections in json file as is. Having the full set of parameters (which are used at the client-side) listed in json file it can serve as a sample (template) for anyone who works on connectors. The devs can see which parameters are used and aware which ones they are able to override and they don't have to guess.

Of course each connector will have the own config file and the own implementation of the "init" method, so the things like ClientSideRegex/ServerSIdeRegex are totally up to connector's maintainer. The main thing about "init" method is that it should return response which coincides with config file object, for example:

{
  "upload": {
      "numberOfFiles": 12,
      "fileSizeLimit": 16000000,
    },
  "security": {
      "uploadRestrictions": [
        "txt",
        "csv",
        "doc"
      ],
    },  
}

That is my vision of that feature.
Do you have any ideas on how to improve it?

[fabriceci]

Indeed the API is required (my bad).

That's the same idea I tried to explain, I agree with that!

With the optional ability to overload the config, we will have a high flexibility!

[psolom]

Great. I'm going to implement that after finish with JSON API standardization.

[psolom]

Closed with the release RichFilemanager v.2.0.0