I think I'd have the same issue since the continue url would be relative to appspot unless I specify it fully, but that results in a 500 =(. However, if someone got it to work please let me know!
On Wed, Mar 21, 2012 at 4:22 PM, Jeff Schnitzer <[email protected]> wrote: > Not sure if this will help you, but we've been reasonably happy with > CloudFlare's SSL support. It provides SSL to CF's edge, then http > between CF and Google - not great if you're taking CC#s, but perfectly > adequate for protecting against FireSheep-type attacks. > > We aren't using Google auth, however. > > It might be another option to try - it might simplify things, and the > non-SSL hop on the final leg might solve redirect issues. At the very > least it means you don't need to maintain the proxy. > > Jeff > > On Wed, Mar 21, 2012 at 6:49 PM, tarun2000 <[email protected]> > wrote: > > I'm posting my workaround that I've implemented for anyone that may be > > interested in the future. I'd also appreciate feedback. > > > > 1) Client hits https://mydomain.com/blah which goes through EC2 proxy > > https://appid.appspot.com/blah > > 2) The client is redirected to the google login page, with continue set > as > > /aa?continue=/blah > > 3) Client logs into Google Accounts and is then redirected to > > https://appid.appspot.com/aa?continue=/blah > > 4) Client hits https://appid.appspot.com/aa which serves a redirect to > > https://mydomain.com/sc?c=ACSID&continue=/blah where ACSID is the Google > > account session cookie read by the handler for /aa. > > 5) Client hits https://mydomain.com/sc?c=ACSID&continue=/blah which > sets the > > ACSID session cookie for the domain mydomain.com and redirects to > > https://mydomain.com/blah based on a continue parameter in aa passed to > sc > > > > Following is my web.xml > > / is publicly accessible > > /aa is publicly accessible > > /sc is publicly accessible > > /* is restricted to logged in users > > > > Following is the restriction in the handlers (with some tricky url > > escaping): > > / --> if not logged in, redirect to login page continue=/aa > > /aa --> if not logged in, redirect to login page continue=/aa > > /sc --> if not logged in, redirect to login page continue=/aa > > /* --> if not logged in, redirect to login page continue=/aa?continue=* > > > > After this, the user service seems to work normally even when going > through > > a proxy serving with SSL. The ACSID cookie is now on mydomain.com and > sent > > through the proxy to appengine. > > > > The appspot domain will still show up to tech savvy users, but this is > not > > my main concern. My goal is to serve over https and keep my customdomain > in > > the url bar and be more secure with user data as serving over no SSL > using > > my custom domain. Since the entire transaction is over https, I don't > think > > this exposes the session cookie any more than using mydomain.com without > > SSL. Any other cross site attacks would work even without this scheme > > anyway. > > > > I'm still not sure why mydomain.com/_ah/conflogin?state=blah fails and > > requires this workaround. > > > > On Tuesday, March 20, 2012 8:37:40 PM UTC-7, tarun2000 wrote: > >> > >> I set up a reverse proxy with nginx on ec2 to provide ssl for my > appengine > >> custom domain. It works until users need to login. The users are > >> redirected to my appspot url after authenticating if I provide a > relative > >> continue url. I tried setting the continue parameter with the entire > url > >> (the one that hits the proxy) instead of just the relative location, but > >> this results in a 500 on appengine when appengine redirects to > >> mycustomdomain?conflogin (which the proxy sends to my appspot url). > >> > >> Is there a way to use Google Accounts and User Service with a reverse > >> proxy or will I need to create my own sign on system? (I know SSL for > >> custom domains is in testing but I'm looking for an immediate solution > since > >> there is no telling when this will be available). > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/google-appengine/-/FbsUXa8YKgAJ. > > > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/google-appengine?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
