Well, an install failed (my install script gets an API key so that it can set the mailgun_api_key). I checked too on my local dev instance.
$ rake api_key:get
rake aborted!
NoMethodError: undefined method `create_master_key' for ApiKey (call 'ApiKey.connection' to establish a connection):Class
Did you mean? create_with
/home/pfaffman/src/discourse/lib/tasks/api.rake:5:in `block in <main>'
Tasks: TOP => api_key:get
(See full trace by running task with --trace)
It’s this commit. @david
Thanks @pfaffman, I’ve made a comment on the PR
Just checking - this is your personal script, not the standard install script?
Yes! This didn’t break a normal install, just the piece of my post-install stuff that needs an API key to set the mailgun_api_key.
I suspect that few people use this rake task.
out of interest, do you clear up the api key when you’re done? You may have noticed I’ve made a lot of changes recently so that we keep better track of API keys. We’re trying to reduce “unused” api keys being left as potential security holes.
If this is running on the server, maybe you could use ruby to set the site setting, rather than generating and using an api key?
Oh! I think it would be better to not change the key if it already exists or to have a create_if_not_exists task. It’s very handy to be able to get the existing key with a rake task without having to change it and break anything that uses the key.
A few places in my Ansible tooling, if I don’t have the API key, I call that rake task to get the existing one, like
- name: Get api key
block:
- shell: docker exec -w /var/www/discourse -i {{ discourse_yml }} rake api_key:get
register: get_api_key
- set_fact:
discourse_api_key: "{{ get_api_key.stdout }}"
when: discourse_api_key is not defined
I guess the only time that it’s really required to get it this way is when I’m doing a clean install. (For existing sites I have the API key in the vars for that site.)
I suppose with the new way that keys are handled I could delete the key when I was done or, say, somehow change site settings by running a rails script inside the container?
One change I made is that you can now have multiple keys per user (or multiple ‘master keys’). That means that every integration can be given it’s own key, and they can be audited/revoked/deleted separately. So in your case, you could create a key with the description “pfaffman’s setup tooling”. Then site admins know what it’s for, and can revoke/delete when it’s no longer needed.
As for how that translates to a rake task… I’m not sure. Maybe we could have a task that was api:get_or_create "my key description" 
Would that work for your case @pfaffman?
Sure! I think that would be just great.
How’s this?
rake api_key:get_or_create_master["Onboarding Key"]
If there are no objections I’ll merge it in a few hours
Looks good to me! And my playbook was still up in my editor, so I’m already committed. 
This topic was automatically closed after 2 days. New replies are no longer allowed.
Sorry @pfaffman, but I’m afraid I will have to remove this new rake task in an upcoming PR. We are going to be hashing API keys in the database, so it will be fundamentally impossible to retrieve an existing key.
https://github.com/discourse/discourse/pull/8438
I’ve replaced the get_or_create_master task with a simpler create_master task, which will unconditionally create a new key. If you want to only have one key, then you will need to keep track of the key in your own system.
Yeah. I sorta figured that was coming. Other systems show the API key only once, so…
Thanks for the heads up!
I can’t quickly tell. (Wait. How is there no schema.rb in the db directory?)
If I do multiple rake api_key:create_master['some name'] with the same some name, will it fail? That is, does that name need to be unique?
Descriptions do not need to be unique, no. Although it could get quite confusing if you make lots of keys that look the same.
We don’t commit the schema.rb file. The best place to look is the annotations at the bottom of each file under /app/models
Wait. What?! Since when? Whatever commit I have in my current discourse source on my hard drive still has schema.rb. It’s really, really, handy to be able to find out just what model that you might be looking for. Being able to open up a single file and search for something (e.g., to figure out which model you might be looking for) is much easier than looking in >200 files in app/models. There isn’t even a good way to be able to grep at just the schema at the end of the models.
If you don’t know what model you’re looking for, how can you find it? Like there are a bunch of tables having to do with “auth”, not all of which start with auth, how can you begin to figure out where to look?
Since always, it’s in the .gitignore file. But it gets generated when you db:migrate, so that’s why it is present locally.
The table name always matches the name of the model, so I just use the filenames 
Aha. Well, shows what I know. :wink thanks for the explanation.
Sometimes I can’t guess the name of the table /model so having all the fields in one place is a big help.
This topic was automatically closed after 25 hours. New replies are no longer allowed.