MVP2/First Release meta-issue

[JackMc]

This is an issue of all of the things we need to do to get to a first release. Feel free to file your own issues and add them to this ticket.

• Basic authentication (either better documentation of how to set up HTTP basic auth or our own small in-house solution. The former would be better as it would maintain the lack of database for this application. If anyone knows any solutions for authentication which don't require a database, let me know!). This is issue Needs some form of (optional) authentication #26.
• Better naming solution for sites. This means that individual sites, by default, should have a name that matches their site domain name (or a new option). If there is an API call for the thing which @wardi was talking about (the settings panel) we could very well just use ckanapi or a web request to do this. This is issue Child sites are named with MAIN_ENV_NAME, not with child site name #25
• Update README.md file to reflect recent advancements in the run.sh automated install. Also document manual installation if people don't just want to run a script. Issue docs: document installation procedure #5.
• Creating a new site overwrites development.ini datacats#298

[JackMc]

So as of c75d776 we have an authentication scheme which is just a simple password (we can add a username later if needed). It currently uses a session cookie encrypted with the app secret and SHA256 hashing with salt.

I really would like some review on this as my crypto-fu isn't great. @wardi

[waldoj]

FWIW, it's really trivial to provide HTTP Basic authentication. You just have to send a couple of HTTP headers to the client, and compare the response to wherever you store the username and password in. I do this every time I think "I need admin authentication for this system I built, but I don't want want it to be a whole thing."

[JackMc]

If you'd prefer HTTP basic auth, I can do that, it's just that I'm not familiar with it.

[waldoj]

It's all the same to me. :)

[JackMc]

So we just had a little bit of a discussion in the office regarding actually naming the sites.

There is now a 'display name' field in the ckan-multisite admin panel, and it is pretty easy to change. Problem is, it doesn't actually impact the real site name. We have a couple options here:

1. Wait for the better option of using the database-based settings in CKAN 2.4.
2. Use a simple insertion into the database in the same place that CKAN stores the site title from the preference panel that Ian was talking about. Hacky, but this is probably the best solution for automated deployments on CKAN 2.3.
3. Give a template title for it and let the user set it to what they'd like (easiest, but least automated)

Thoughts, @waldoj?

[waldoj]

Hmm. There are no great options here, but ¯_(ツ)_/¯. Point by point:

1. What's the timeline for CKAN 2.4?
2. I agree entirely with your assessment.
3. I don't follow. Could you explain the UX here? It sounds like this might be egregious.

[JackMc]

CKAN 2.4 itself is out but we are waiting for our release manager to come back to put out a release of the datacats tool

[JackMc]

Re: 3. is similar to what you suggested before, call any new site "A Multisite Site" and in the "promoted" section we mention that they should change the site title in there

[waldoj]

CKAN 2.4 itself is out but we are waiting for our release manager to come back to put out a release of the datacats tool

Got it. I'm much less confused now. :)

1. is similar to what you suggested before, call any new site "A Multisite Site" and in the "promoted" section we mention that they should change the site title in there

Ahh, I see—so it remains possible for people to change the name on a new site, this is just about eliminating that step.

[waldoj]

So, this is my preference, but ultimately I'm happy to defer to your judgment: Option #2, with the intent of ripping it out when CKAN 2.4 support obviates that hack. It's ugly, but I suspect it'd be quick and easy, and likewise easy to remove down the line, if it's anything like the "I'll just directly write this thing to the database" hacks I've been guilty of over the years. :)

[JackMc]

Yup, I was trying it out today. The only catch is that we may need to shut down CKAN itself to change the site name as it will not reread from the database automatically - this is not ideal.

[deniszgonjanin]

@JackMc you make us sounds so formal, heh. Ian is gone camping for a few days and will be back Tuesday to push out a new release. That's the alternate timeline

[waldoj]

So perhaps the site name is set at the time that it's created, and future changes must be performed through the deployed CKAN site's admin section? That way, the only restart required is in the process of establishing the site in the first place, delaying its launch briefly. I think that's a perfectly reasonable solution for an MVP.

[JackMc]

Sounds good!

[JackMc]

@deniszgonjanin Sshh, next you're gonna let it slip that I don't wear a suit to work!

[waldoj]

Ian is gone camping for a few days and will be back Tuesday to push out a new release.

Yay for camping. :) If the alternative is just waiting a few days until Ian can get out a new datacats release, that sounds great.

The wonderful thing about working in open data is there's no such thing as an open data emergency. :) Basically everything can wait.

[JackMc]

There isn't much needed here technical-wise. If you could have another go at this @waldoj that'd be lovely! :)

[JackMc]

I'm gonna close this issue.