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 On Tuesday, July 21, 2015 at 11:14:17 AM UTC+3, Kaan Soral wrote: > > 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? > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/2110b134-594a-4092-80f9-0f5d084ea3ab%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
