Managing credentials for other services used by an App Engine app.

129 views
Skip to first unread message

Frederik Creemers

unread,
Sep 19, 2015, 2:20:37 PM9/19/15
to Google App Engine
It's not good practice to store credentials in your source code repository, but App Engine has no other way to inject these into your app. Something like heroku's config variables would be great, or is there an existing way to do this that I'm not aware of?

PK

unread,
Sep 19, 2015, 4:32:22 PM9/19/15
to Google App Engine
I find this as an issue as well, I would love to hear how others solve it. Start a tracker issue, I will star it.

On Sep 19, 2015, at 11:20 AM, Frederik Creemers <frederik...@gmail.com> wrote:

It's not good practice to store credentials in your source code repository, but App Engine has no other way to inject these into your app. Something like heroku's config variables would be great, or is there an existing way to do this that I'm not aware of?

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/99c73026-edc5-429c-b415-49f17f6c79c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Chad Vincent

unread,
Sep 21, 2015, 10:51:46 AM9/21/15
to Google App Engine
We have a link to an external application, and just put the credentials (In this case, an API key with a matching username) in our User objects, and if it's a system-level event, it uses the key from the Administrator user.

For anything that is global, we were just going to build an object in the Datastore that will be editable via our own Admin console.

Frederik Creemers

unread,
Sep 21, 2015, 12:58:48 PM9/21/15
to Google App Engine
Hi Chad

That's a nice solution to the problem, and it might be the best thing to do given the current environment, but I don't like mixing configuration/credentials management with the database layer. This would mean that if the datastore is unavailable, I don't have access to my config.

--
You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/PEfvmvSQOPY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-appengi...@googlegroups.com.

To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.

Nick (Cloud Platform Support)

unread,
Sep 21, 2015, 1:43:21 PM9/21/15
to Google App Engine
Hey Frederik,

Usually it shouldn't be a problem to include credentials in your deployed package so long as you ignore it from tracking by your source control tool (gitignore). 

This is my advice on how to avoid storing credentials in your source control system.

Best wishes,

Nick

Chad Vincent

unread,
Sep 21, 2015, 3:02:30 PM9/21/15
to Google App Engine
For our application (and I feel like most applications), if the datastore is unavailable, any action being performed will error with or without the other credentials.  And if you use a fixed ID (or set) for the credentials and a caching persistence layer like Objectify, you'll likely have a copy of those credentials in Memcache and possibly the session cache.

Obviously, if you are less dependent on the datastore (or CloudSQL), that would make a difference from a design level.  But for us, lacking access to the datastore makes access to external creds moot.

Chad Vincent

unread,
Sep 21, 2015, 3:03:27 PM9/21/15
to Google App Engine
Oh, and it also means we can update those creds without having to perform a full deploy.  :)

Frederik Creemers

unread,
Sep 21, 2015, 3:45:18 PM9/21/15
to Google App Engine
@Nick, then you lose all the advantages of push to deploy;
@Chad Yeah, I think it's your best bet atm.

Nick (Cloud Platform Support)

unread,
Sep 23, 2015, 3:15:51 PM9/23/15
to Google App Engine
Correct, if you have a requirement for push-to-deploy, you'll need to get your credentials into your app another way; persisting them provides availability to the runtime, and separates deployments from credential-change events.
To unsubscribe from this group and all its topics, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages