Search the FirstSpirit Knowledge Base
Dear FirstSpirit-Community,
in different cases, an explicit FirstSpirit connection is needed via:
ConnectionManager.getConnection()
to allow executing administrative tasks provided in FirstSpirit modules or FirstSpirit BeanShell scripts.
To prevent, always specifying the Admin-User credentials (Password) in the local code, we wonder how to centralize that information. Currently, there is no API call available like:
User.getLoginPassword()
There is only a setter to write the password to the user object via:
User.setLoginPassword()
By providing a centralized solution, we could just update the Admin password at one place. Otherwise, there is a need to update a potentially changed Admin password in different locations :smileyangry:
Suggestions are highly appreciated!
Kind regards,
Holger King
Dear Mr. King.
There is no such method because we don't deliver user passwords from the server. Such functionality would be a security leak.
If you want to store the (technical) user credentials centralized, you can use CMS_INPUT_TEXT components (password mode) in the project settings and implement your scripts to read from them.
Best regards,
Bernd Eßmann
Dear Mr. Eßmann,
your suggestion to offer a project setting input field where to store an FirstSpirit-Admin account credential is very poor. The reason:
- the solution is not really centralized because it's project specific
- the project settings template might potentially vary between projects
Maybe a better solution would be to offer a module service component including a configuration dialog where to administrate the FirstSpirit admin credentials. Accessing it from template, BeanShell-scripts and module components might be easily possible.
What about that solution?
You can do that, just keep in mind that a service is accessible by every other module on that server, which might be a security issue. So you might want to restrict access to the admin password to trusted modules/code only.
Hi Christoph,
how to restrict access to just trusted modules/code only? How would you prefer doing that?
You could analyze the caller stack and have a whitelist, require a secret password... So it's up to you.