2

I have a fairly simple problem currently but I cannot get a solution, maybe someone here has a good idea.

I am working on an open source CMS for artists called Jinya CMS. The whole project originated in a friend of mine needing a new website for her artwork so I started to build her a website fitting her needs. One of those needs was that it is based on PHP, that is why I chose Symfony as base.

Right now I am developing version two and I would like to add an option to submit ideas on how to make things better in the administration. My idea is a simple bug and feature request form and then the data is added to the public trello board. Apart from that an email is going to be sent, which goes to the developers of the project (currently me) who can then react.

My problem is now the following, I need to store credentials for the trello board access and the email account sending the data.

Here are the ideas I had by now and why I think they are not good.

  • Integrate ionCube Loader
    • ionCube is nothing bad but it just doesn't feel right to encrypt data in an OpenSource project, also I don't know if it runs on her webspace stable enough, I read it doesn't.
  • Separate web api for that purpose
    • This idea is my current favorite, cause it would eliminate the issue of encrypting OpenSource software and it would solve the issue I have. By putting all the credentials in the configuration I would also be able to license that code under MIT on Github, like the rest of the project.

Now comes the question, is this a viable way to go or are there better ways? I think there must be a better way. Does anyone know?

To clarify, the credentials I am talking about are only known by me no one else.

  • 3
    I think the only way is your current favorite option: use a separate web api. It is widely used throughout the industry for analytics, diagnostics, feedback and many more applications. For example, take a look at how Google or Microsoft handle these types of input. However, you will need to really think about having a public-facing API - one that could be abused by tech-savvy users who extract the requests from your code or find them using a network sniffer. – Ivo Coumans May 15 '18 at 11:29
  • Doesn't Trello allow you to create a public user with read-only rights? – JoeriShoeby May 15 '18 at 15:30
  • @JoeriShoeby I need to write the cards, so readonly doesn't help. – Knerd May 15 '18 at 15:43
  • @IvoCoumans Yeah, for now that is the solution I chose and it was pretty simple to implement. I think I will add a kind of registration process to the api so you cannot abuse it that easy. – Knerd May 15 '18 at 15:44
  • 1
    Go for the second, it's future proof for more CMS instances, and you are able to instantly block a CMS from spamming in case of abuse. You've got way more control over your deployments. – JoeriShoeby May 15 '18 at 16:20
1

In your situation, I think the only viable option is your current favorite: use a separate web api. It is widely used throughout the industry for analytics, diagnostics, feedback and many more applications. For example, take a loot at how Google or Microsoft handle these types of input.

However, you will need to really think about having a public-facing API - one that could be abused by tech-savvy users who extract the requests from your code or sniff them using other tools.

As @JoeriShoeby mentioned in a comment, it's also very future-proof and powerful in controlling input from specific deployments.

9

You can put that sensitive data (emails, API keys) in a separate "env" file which is not added to version control but instead configured during deployment.

For ease of use you can include in VCS an "env.example" file with all the values that should be filled for the project to run fine.

Laravel does this: https://laravel.com/docs/5.6/configuration#environment-configuration

e.g.

In "env.example" (committed to VCS):

EMAIL=
TRELLO_API_KEY=

In "env" (exists only on the deployed project):

EMAIL=the.real.email@example.com
TRELLO_API_KEY=theRealApiKey
  • That wouldn't really help, cause when someone uses the CMS on their server it will not be deployed. – Knerd May 15 '18 at 10:26
  • 1
    I read the comments in the original question and I think that I understand the issue now (the CMS will be installed by other people). So yep, your second option seems the best one. – Armando Garza May 15 '18 at 17:51
2

Some Open Source projects solve this by doing a one time setup screen when you log in the first time where you set the password. The downside is the app needs rights in the DB to change a user password.

Otherwise I would leave a placeholder in a config file for it and have the application throw an exception if the password isn't set or is still the default.

  • This wouldn't really solve it, I want to set credentials only I know not the user. – Knerd May 15 '18 at 10:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.