Google App Engine version 1.9.24 SDK available
171 views
Skip to first unread message
Sarah Murphy
Jul 20, 2015, 2:21:34 PM7/20/15
to google-a...@googlegroups.com
Greetings!
Please examine the most recent release of the GAE SDK here.
All
- In all the App Engine SDKs, authentication for app deployment is now exclusively through OAuth2. Authentication using an email address and password is no longer supported and the --no_oauth2 flag is no longer available. Note that email address/password authentication will also soon cease to work for older SDK versions.
- The list of email addresses that can appear in the “from” field of an email sent by an app is now managed through the App Engine Settings page in the Developers Console.
- URLFetch’s URL length limit of 2000 characters is removed.
- URLFetch will expand titlecase usage for HTTP headers to HTTPOverRPC.
- Datastore Admin now works with Chrome 44.
Kaan Soral
Jul 21, 2015, 4:14:17 AM7/21/15
to google-a...@googlegroups.com
The password depreciation breaks my workflow at extremes
1) I have an old project with a dedicated and modified old SDK, I'm not sure whether an updated SDK would be able to accommodate that project
2) I'm unsure how the new deploy command works, at the very least, a forced SDK update breaks my new workflow too, as I have to manually modify the SDK I use to mend the shortcomings and various bugs
I guess a logical solution for both issues to use a third SDK, just for deployments - assuming it's still possible to deploy from the CLI
Out of curiosity, how much does the oauth workflow increase the security - isn't the existing password routine secure? Or is it just there to ensure the SDK password routine is compatible with the rest of the google password routines and it's too much of an effort to keep the existing routine?
Nick (Cloud Platform Support)
Jul 21, 2015, 2:22:57 PM7/21/15
to google-a...@googlegroups.com, kaan...@gmail.com
Hey Kaan,
The email authentication for old versions will continue to work for a short time, so you should be able to transition those projects to interface with OAuth using the --oauth2 flag and the appcfg oauth2 credentials generated by going through the oauth2 flow once with either an old or new SDK.
As to your patched SDK, if you have patches to make to the SDK, and you rely on services that SDK interfaces with, you should submit patch requests to the public issue tracker so that you don't end up having to maintain what amounts to a fork which still has the responsibility of keeping up with developments to the underlying service.
If your old patched SDK is only needed for development and you don't wish to submit the patches for "shortcomings and various bugs", then you could of course, as you say, use the new SDK to deploy and use the old patched one to develop. Be aware that this cuts you off from future development server releases unless you do the hard work of merging the fork back into the main branch developed by Google in future releases.
I can't comment authoritatively on the reason for removing password authentication but if I were to make an informed guess it's likely because the security features of having a single authentication flow at a single location (accounts.google.com login when you go through a login flow) making it preferred over sending passwords through a side channel maintained by App Engine and the SDK. Otherwise the certificates and encryption involved would need to be maintained and upgraded in parallel, etc. This is just one possible line of reasoning, not a comment from a dev involved.
Sincerely,
Nick
The email authentication for old versions will continue to work for a short time, so you should be able to transition those projects to interface with OAuth using the --oauth2 flag and the appcfg oauth2 credentials generated by going through the oauth2 flow once with either an old or new SDK.
As to your patched SDK, if you have patches to make to the SDK, and you rely on services that SDK interfaces with, you should submit patch requests to the public issue tracker so that you don't end up having to maintain what amounts to a fork which still has the responsibility of keeping up with developments to the underlying service.
If your old patched SDK is only needed for development and you don't wish to submit the patches for "shortcomings and various bugs", then you could of course, as you say, use the new SDK to deploy and use the old patched one to develop. Be aware that this cuts you off from future development server releases unless you do the hard work of merging the fork back into the main branch developed by Google in future releases.
I can't comment authoritatively on the reason for removing password authentication but if I were to make an informed guess it's likely because the security features of having a single authentication flow at a single location (accounts.google.com login when you go through a login flow) making it preferred over sending passwords through a side channel maintained by App Engine and the SDK. Otherwise the certificates and encryption involved would need to be maintained and upgraded in parallel, etc. This is just one possible line of reasoning, not a comment from a dev involved.
Sincerely,
Nick
Reply all
Reply to author
Forward
0 new messages