Reverse Proxy for custom domain SSL and Users Service possible?

[tarun2000]

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).

[Richard Watson]

How about having the continue url page check if it's being called on appspot, and then forwarding to your 'correct' url? Then you can continue using Users etc and just have a tiny bounce in-between that'll be hardly noticeable. Using Users is a longer-term decision, the current problem is (hopefully) temporary.

[tarun2000]

I don't think that would work.  If I login and get redirected to blah.appspot.com, then manually go to securedomain.com, it doesn't realize I'm logged in.  The cookie for auth gets set for blah.appspot.com instead of for securedomain.com.  I don't see why automating the redirect would do something different.  I suppose I could try copying the cookie... if I can figure out which one it actually needs, though it seems a bit flaky.

[tarun2000]

Manually copying the ACSID (in Firefox) during this redirection seems to work.  I shall see how well it holds up automated.

[tarun2000]

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.

[Jeff Schnitzer]

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

> --
> 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 google-a...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengi...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.

[Tarun Pondicherry]

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!

[Richard Watson]

Two questions:

1) Why only 'reasonably' happy? Anything you didn't like?

2) Brandon has said they've had to save customers from CloudFlare in the past. You haven't hit any of those issues?

[Jeff Schnitzer]

On Thu, Mar 22, 2012 at 3:34 AM, Richard Watson
<richard...@gmail.com> wrote:
> Two questions:
> 1) Why only 'reasonably' happy? Anything you didn't like?

The documentation is a little thin - for instance, I had to
experimentally discover the special header which indicates whether the
original request was SSL or HTTP (so I can redirect http->https). The
initially issued SSL cert was somehow broken so they had to reissue
it. But the service works fine and provides the best interface to
hosted DNS I have yet worked with.

> 2) Brandon has said they've had to save customers from CloudFlare in the
> past. You haven't hit any of those issues?

I haven't hit anything, but we aren't seeing much traffic yet. For us
(https://www.voo.st/) the main benefit today is SSL. I say
"reasonably happy" because we really haven't exercised CF heavily so I
can't give it a confident endorsement. But so far all lights are
green.

Jeff

[PK]

Hi Tarun,

I am hitting the same problem today. Did you find any solution?

"I'm still not sure why mydomain.com/_ah/conflogin?state=blah fails and requires this workaround."

Thanks

PK