Hi Dakota, You haven't mentioned what will be calling your service? (JavaScript, iOS, or Android)
If you've really never done it before, I would suggest you grab the Identity-Kit sample and just build from that. It's really easy to put that up and extend it. https://github.com/googlesamples/identity-toolkit-python Since you are mentioning Django, There are quite a few other versions. When I don't want GoogleAuth, I often will just roll my own API instead of using EndPoints. I find I can do simple JSON API's in very few lines of code. Just make sure to require HTTPS. Les On Thu, Jan 1, 2015 at 12:50 AM, timh <[email protected]> wrote: > I have implemented traditional user/pass on top of repoze.who/repoze.what, > that also supported google auth and could be easily extended. > However it's not my code (wrote it for another organisation), so not in a > position to share (currently it is used by somewhere between 2000 and 3000 > users). > > I haven't seen a well packaged lib for doing this, (though they might > exist). > > Though did come across this - > https://github.com/abahgat/webapp2-user-accounts > > I would consider looking at something like webapp2-user-accounts and > pulling the core of it out and making it a provider for authomatic. > > Then you can support multiple auth methods. > > Cheers > > Tim > > > On Thursday, January 1, 2015 1:23:27 PM UTC+8, Dakota Pitts-Price wrote: >> >> Thanks lol but its not temping to roll out my own solution at all. >> I am sorta a noob, so I would like to use a vetted and easy to implement >> solution. >> Automatic looks nice, thanks for the recommendation, but it does not >> appear to support its own authentication. >> As I move beyond something as dead simple as Parse, I still want to >> maintain the ability to offer traditional user/pass logins. >> This is a requirement with a majority of my clients as well as with users. >> >> On Wednesday, December 31, 2014 5:39:56 PM UTC-10, timh wrote: >>> >>> I know it's tempting to roll your own, but I would have a look at >>> automatic first. >>> >>> http://peterhudec.github.io/authomatic/index.html >>> >>> On Thursday, January 1, 2015 11:01:43 AM UTC+8, Dakota Pitts-Price wrote: >>>> >>>> Thanks for your support Les. >>>> >>>> I find it shocking that for all its amazing features the GAE has, it's >>>> built in username/password system is such a second class citizen. >>>> I understand the complexity and ease of getting it wrong, which is why >>>> I hoping to find an easier to roll out solution than building it from the >>>> ground up. >>>> Personally I also learn the best that way. >>>> >>>> I see a modified Django is supported on the GAE. I have no experience >>>> with this framework, but I would rather spend the time to learn that than >>>> roll out my own Auth system on top of end points. >>>> Are there any caveats to using Django on GAE? I understand I wouldn't >>>> be able to use the nifty Cloud End Points. >>>> I am only currently looking to have 7 REST Apis that deliver JSON plus >>>> one or two tasks that run once a day. >>>> Is Django over kill for that level of requirements? Is there an easier >>>> solution? >>>> >>>> Sorry about all the questions and thanks again! >>>> Dakota >>>> >>>> >>>> On Tuesday, December 30, 2014 10:00:27 PM UTC-10, Les Vogel wrote: >>>>> >>>>> Hi Dakota, >>>>> >>>>> First off, Identity-Toolkit is separate from Endpoints, so using it >>>>> would require you rolling your own solution for Endpoints -- similar to >>>>> what I describe below. >>>>> >>>>> What I'm about to describe is a very simplified version of what's >>>>> necessary, I recommend reading the standard docs for OAuth2 as there are >>>>> some very subtle and tricky things about security. (ie. I'm simplifying >>>>> things to answer the Q using our API's and our accounts is best practices, >>>>> what I'm describing probably could be improved by a security expert) >>>>> Because of this, I will not be using specific nomenclature to >>>>> differentiate this from a good solution. >>>>> >>>>> Your login mechanism can return a token (like a JWT <http://jwt.io/>) >>>>> that should contain at least an identifier of who the user is, an >>>>> expiration date/time for the token, and be cryptologically signed. You >>>>> pass that token as one of the parameters in your Endpoint, you ALWAYS >>>>> validate the signature then the expiration time. If either is invalid, >>>>> you >>>>> reject the token. >>>>> >>>>> You can include a refresh method, or just require re-login to get a >>>>> revised token. My go code >>>>> <https://github.com/GoogleCloudPlatform/abelana-gcp/blob/master/endpoints/tokens.go> >>>>> has most of this. >>>>> >>>>> One last disclaimer - This stuff is very hard to get right! >>>>> >>>>> Below was from a private message I sent about this last week. It has >>>>> both the Java and Android (java) changes. Where you see the word "secret" >>>>> send your token. (This had a constant secret for his application). >>>>> >>>>> Regards, >>>>> >>>>> Les >>>>> >>>>> From: >>>>> https://github.com/GoogleCloudPlatform/gradle- >>>>> appengine-templates/tree/master/HelloEndpoints >>>>> >>>>> If you look at the code: >>>>> >>>>> context = params[0].first; >>>>> String name = params[0].second; >>>>> >>>>> try { >>>>> return myApiService.sayHi(name).execute().getData(); >>>>> } catch (IOException e) { >>>>> return e.getMessage(); >>>>> } >>>>> >>>>> >>>>> Which came from your java code: >>>>> >>>>> @ApiMethod(name = "sayHi") >>>>> public MyBean sayHi(@Named("name") String name) { >>>>> MyBean response = new MyBean(); >>>>> response.setData("Hi, " + name); >>>>> >>>>> return response; >>>>> } >>>>> >>>>> You can see the service "sayHi(name)" to add the secret, you could do >>>>> the following >>>>> >>>>> redefine your service to include secret: >>>>> >>>>> public MyBean sayHi(@Named("secret") Long secret, @Named("name") >>>>> name) { >>>>> if(secret != 32753454453456L) return null; >>>>> ... >>>>> } >>>>> >>>>> And the code would become: >>>>> >>>>> return myApiService.sayHi(secret, name).execute().getData(); >>>>> >>>>> On Tue, Dec 30, 2014 at 3:40 PM, Dakota Pitts-Price < >>>>> [email protected]> wrote: >>>>> >>>>>> Hey Les, >>>>>> >>>>>> If I wanted to have my own login system and still use the Cloud End >>>>>> Points with some form of Auth, how would you advise going about starting >>>>>> this? >>>>>> >>>>>> Thanks for your help :) >>>>>> >>>>>> On Tuesday, December 30, 2014 1:37:07 PM UTC-10, Les Vogel wrote: >>>>>>> >>>>>>> Hi Dakota, >>>>>>> >>>>>>> You might wish to look at the Identity-Toolkit >>>>>>> <https://developers.google.com/identity-toolkit/> or Firebase >>>>>>> <https://www.firebase.com/> for general purpose Auth. >>>>>>> >>>>>>> For GAE, you can have general gmail or domain specific auth -- ie >>>>>>> all Google accounts (Gmail, Google for Work / Education / Business / >>>>>>> Government, and anyone who's logged into Google). >>>>>>> >>>>>>> Correct - If you roll your own, you can't use GAE login or Endpoints >>>>>>> with Auth enabled. Nor can you roll your own Oauth2 and insert it into >>>>>>> Endpoints. You could issue your own Tokens and pass them as parameters, >>>>>>> always requiring HTTPS, however. I have a few examples of this using >>>>>>> Identity-Toolkit, but they are for Go & Android. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Les >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 30, 2014 at 1:10 PM, Dakota Pitts-Price < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi I am noob looking to expand my knowledge base outside of heavily >>>>>>>> managed services like Parse. >>>>>>>> I have done a few jobs in Parse, but I am looking for something >>>>>>>> that is more flexible and cheaper to use as an App Backend. >>>>>>>> I think the GAE is a good stepping stone, but I keep coming across >>>>>>>> the issue of Authentication. >>>>>>>> >>>>>>>> >>>>>>>> First it appears that there is no out of the box easy way to do a >>>>>>>> simple username and password login. >>>>>>>> -It seems like the best approach to this is using Django >>>>>>>> --Is there an equivalent framework in Java that is GAE compatible? >>>>>>>> >>>>>>>> Second it appears if you using your own Login system you can't use >>>>>>>> the builtin Auth with Google Cloud End Points >>>>>>>> -So it seems if you want to use the builtin Auth with cloud end >>>>>>>> points and still maintain control of your user login I would need to >>>>>>>> host >>>>>>>> my own Oauth2 Service. >>>>>>>> --Is there a way for me to host my own Oauth2 Service inside of the >>>>>>>> GAE? >>>>>>>> --This seems like how AWS works, should I consider just starting on >>>>>>>> their system instead of GAE? >>>>>>>> >>>>>>>> Thanks for reading :) >>>>>>>> >>>>>>>> *-Side note* >>>>>>>> *I have been Googling and researching this for about two days now >>>>>>>> and am surprised at the communities lack of support for non Google or >>>>>>>> non >>>>>>>> major Oauth user authentication in GAE.* >>>>>>>> *It is out of the question for many of my clients to not have self >>>>>>>> authentication for their apps/sites.* >>>>>>>> *So having an easy solution is important for me as I learn how to >>>>>>>> use a more powerful and complicated service. (pardon my noob, I have >>>>>>>> only >>>>>>>> been coding for a year or so)* >>>>>>>> >>>>>>>> *Also a lot of people respond negatively saying users don't want >>>>>>>> another account to remember, users don't want to trust you with their >>>>>>>> password, and you shouldn't want the responsibility.* >>>>>>>> *But none of that is true, every app I have worked on when given an >>>>>>>> option more users use username/password than a third party Oauth >>>>>>>> provider.* >>>>>>>> *Thus having the option is curial.* >>>>>>>> *Also its not unreasonable for a client to not want to rely on a >>>>>>>> major third party to authenticate their user base.* >>>>>>>> *I understand that this is putting more responsibility on me, but >>>>>>>> if the app is a simple little thing I imagine the users use a simple >>>>>>>> little >>>>>>>> password. * >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>>>> . >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Les Vogel | Cloud Developer Relations | [email protected] | >>>>>>> 408-676-7023 >>>>>>> >>>>>> -- >>>>>> 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. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Les Vogel | Cloud Developer Relations | [email protected] | >>>>> 408-676-7023 >>>>> >>>> -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- Les Vogel | Cloud Developer Relations | [email protected] | 408-676-7023 -- 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. For more options, visit https://groups.google.com/d/optout.
