That's what I'm going to end up doing. I was hoping there would be a solution that didn't involve an extra HTTP request. If this were some obscure issue, I would have just done my own work around, but with more and more one-page style apps being built and using libraries (or hand-coded js) to enable location, history, and bookmarking capabilities, I figured this might warrant some discussion. However, I can't imagine what kind of process would need to be followed to make a change to how Google Accounts would safely decode a URL component for redirecting (assuming I correctly diagnosed what's going on), so this was mostly a shot in the dark.
Thanks for the response. Your solution is most likely what I'll end up doing. On Apr 2, 1:00 pm, "Ikai L (Google)" <[email protected]> wrote: > Would it be possible for you to create a handler that does a 302 redirect to > a URL with a hash mark? That is: your full continue URL looks like: > > continue=http://something.appspot.com/js_translate/some/uri/here > > At that URI your handle converts that to: > > continue=http://something.appspot.com#some/uri/here > > > > > > On Fri, Apr 2, 2010 at 9:19 AM, Jay Young <[email protected]> wrote: > > I am writing a one-page AJAX driven site, meaning that every > > interesting part of my app's URL lives after the # mark, for example > >http://example.appspot.com/#/view/item/25/. When a user logs in or > > out, I would like them to be redirected back to that address, so when > > they click login or logout, they are sent to a script on the server > > along with a 'referer' string. The script generates the login/logout > > url via users.create_log(in|out)_url(referer). This gives me a proper > > address with the correct "continue=..." value. The script then > > redirects them to that login/out URL. > > > The problem is that once the user follows through on the > > authentication page, they are redirected to the base URL for my app > > ("http://examples.appspot.com/";) even though the full "continue=" > > parameter was "http://examples.appspot.com/#/view/item/25/";. I > > suspect that the browser is terminating the "continue=" parameter at > > the hash mark, thinking it is trying to refer to a non-existent anchor > > on the current page. Unfortunately, even escaping the hash mark in > > the create_login_url() function doesn't work, because then the Google > > Accounts page tries to redirect the user to "http:// > > examples.appspot.com/%23/view/item/25", which is not correct, as the > > URL is never decoded. > > > If the Google Accounts page could specifically check for that encoded > > hash mark and decode JUST that character before doing the redirect, > > this would work just fine. As it stands, I have to live with > > redirecting users back to the base page of my app. > > > Note: I don't remember if '%23' is the proper encoding for '#'. I > > was using Javascript's encodeURIComponent function in attempting to > > encode it, so I know it's not just a simple matter of using the wrong > > encoding. > > > -- > > 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]<google-appengine%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-appengine?hl=en. > > -- > Ikai Lan > Developer Programs Engineer, Google App > Enginehttp://googleappengine.blogspot.com|http://twitter.com/app_engine- Hide > quoted text - > > - Show quoted text - -- 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.
