Public Instance of Goblin?

[AlbrightPatents]

It would be nice if there was a public instance of goblin;

People would be able to try it without installing software and whatnot just to see if they like it. For me at least, it was just a massive pain to do, just to try it out. Even if you guys aren't up for it, some pictures would be nice!
In my case, I had two options;

1. Install a new Centos VM, install node, install couchdb, install git, configure the database/user. Which would take a lot of time.
2. Copy a virtual machine from the HV, install and configure couchdb, and then try it.

Any thoughts on this?

[Alpha4615]

I'm thinking of setting up a deployment on my box for this purpose. I could
write a script that gets executed nightly to reset the database and pull
the latest revision.

We'll need to discuss strategy, though. For example should the redeploy
script pull from master, or should the main goblin repo set up a demo
branch? Also how do we deal with trouble makers who change passwords? Do we
set up minutely password resets? Just some things to think about!
On Dec 17, 2013 8:31 AM, "Harry Torry" notifications@github.com wrote:

It would be nice if there was a public instance of goblin;

People would be able to try it without installing software and whatnot
just to see if they like it. For me at least, it was just a massive pain to
do, just to try it out. Even if you guys aren't up for it, some pictures
would be nice!
In my case, I had two options;

1. Install a new Centos VM, install node, install couchdb, install git,
   configure the database/user. Which would take a lot of time.
2. Copy a virtual machine from the HV, install and configure couchdb, and
   then try it.

Any thoughts on this?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/56
.

[PunkChameleon]

This would be an awesome thing to do. I think for now we can use the master branch, maybe when it's use scales we can set up another branch for stability's sake.

As for the password problem, it's not really an issue since there's no user management system in the application yet -- the password is set in 'lib/config.js', and defaults to 'admin' 'admin', so there'd be no way for anyone to change it without having access to the server code.

I think we can do a reset of code and database nightly, or maybe even more often (hourly?) that'd be awesome.

Also, if it helps, there's the CouchDB puppet module (https://github.com/jonbrouse/puppet-couchdb) that was developed because of this project if that helps with the installation process.

[Harry-Torry]

I'm the one who posted this, I was unfortunately just on the wrong account.

Would it be possible to just hardcode the admin password for the purpose of the demo? Or a button on the login page to reset the password if it has changed etc?
That way, nobody would be able to change it, or if they could it'd be easy for a user to reset it.

I'm usually quite against blind fixes (every x seconds reset the password), although it would get the job done for the example purpose.

[Alpha4615]

I'll get on this asap, Nick. Should be fun. I have nothing against hourly
pulls, either.
On Dec 17, 2013 9:20 AM, "Nick Weingartner" notifications@github.com
wrote:

This would be an awesome thing to do. I think for now we can use the
master branch, maybe when it's use scales we can set up another branch for
stability's sake.

As for the password problem, it's not really an issue since there's no
user management system in the application yet -- the password is set in
'lib/config.js', and defaults to 'admin' 'admin', so there'd be no way for
anyone to change it without having access to the server code.

I think we can do a reset of code and database nightly, or maybe even more
often (hourly?) that'd be awesome.

Also, if it helps, there's the CouchDB puppet module (
https://github.com/jonbrouse/puppet-couchdb) that was developed because
of this project if that helps with the installation process.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/56#issuecomment-30754068
.

[PunkChameleon]

@Harry-Torry I think we posted at the same time!

Since there's only one user right now that's hardcoded into 'lib/config.js' it shouldn't be a problem, especially if we leave it as a default and publish it alongside the site.

However, I like you're idea of a reset button if it's extended to reset the entire site. Even as a standalone feature, if you just want to reset the database and start over again (sometimes you just want to nuke the site!). What do you think? That could even be worth logging up as a separate issue and get that moving as a feature.

[PunkChameleon]

@Alpha4615 sounds great! Keep this thread updated on your progress too -- your script could be a good thing to open-source as well!

[AlbrightPatents]

We must have done, cause I only just saw your reply.

For now then, it won't be a problem! I do like the idea of a 'nuke' button, you should call it a NUGE. Nu-Goblin, New Goblin. huehue.

So I've never actually collaborated through Git (or at all really..). Do I just look at issues, fork code and then wait for them to be pulled through? (To help out)

[PunkChameleon]

@Harry-Torry Sounds good to me!

To contribute, you would fork the repository, make changes and then submit them as a pull request. The request will come in as an issue, notify everyone and then be pulled it into the main repository. If you are solving a specific issue, you can put the issue number in your pull request and when it's merged it will close it!

If you have any other questions on the process, feel free to ping me! We'd love your help!

PS - For the nuke option (I like the name ideas!) can you open up a separate issue in Github? That way we can keep it separated from the public goblin issue and make sure everyone knows what's going on!

Thanks again :)

[Harry-Torry]

That makes sense! I'm a lone developer who got a job as a lone developer so I only ever have to push to a test branch, make sure it works and then merge, and I do it with the windows app which simplifies everything, and then in the servers console, 'git pull project master'.

Sure thing, I'll undoubtedly get stuck or mistype something somewhere along the line!

[SotiriosVrachas]

Currently Goblin is not ready for Production, not even Alpha yet. Strategically an public preview instance make sense when the software is in public beta.

A function to reset the database might be a very dangerous future to have, in case that a production website gets compromised it would be a 1-click way ticket to disaster. And "reser every x" is a system task.

The authentication module is multi-user capable, but the config.js has only one entry for a user right now and the password is in plain text.

Every password should be hashed with the pseudo-random salt unique to every site before storage and compared with it for authentication.

The original design for a standalone goblin instance was for a brochure site, where multiple users are not involved. This made original development simpler.

Unfortunately this dose not make much sense in the cloud. And the number one goal of "being the easiest to theme" wouldn't be possible to test without access to the source of the instance with the current state of code.

A solution for all this would be multi site support, separate template folder for every site and a global user table or a per site user table. A global user table would require a Access control list. Separate template folder per site would make filesystem access an issue, so templates should be uploaded from the admin panel, archived or as multifile, and maybe stored in the database. Blobs, css and js that should be accessible from the public should exist on disk or at a cdn. For public preview defiantly a cdn mirror would be nice, goblin could upload everything in the cdn and implement a basePath variable and a function fileUrlAlter() to change relative urls which sould be good for seo too.