My problem with the behavior is that the user has already logged in to Google Apps BEFORE being presented the iFrame. Our GAE application in embedded in an iFrame to provide additional functionality to a Google Site. (The Site is not public, so requires a GApps login.)
After performing the GApps log-in, I would think that I could access a Sites page with a GAE page embedded in an iFrame and have that work without needing to do a subsequent login. But if an additional log-in is required by the iFrame because of the sandbox-nature of an iFrame, then the resulting log-in redirection should occur within that context. Having it break out of the iFrame (which only occurs in Internet Explorer) makes no sense because in the context of the top- level browser window, the user is already logged in. On Oct 14, 3:27 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com> wrote: > Or ... am I misunderstanding what is happening here? > > -- > Ikai Lan > Developer Programs Engineer, Google App Engine > Blogger:http://googleappengine.blogspot.com > Reddit:http://www.reddit.com/r/appengine > Twitter:http://twitter.com/app_engine > > On Thu, Oct 14, 2010 at 12:23 PM, Ikai Lan (Google) < > > > > > > > > ikai.l+gro...@google.com <ikai.l%2bgro...@google.com>> wrote: > > It seems to me like this is working as intended. Putting a login screen > > inside an iframe completely defeats the purpose of having an HTTPS based > > login. > > > -- > > Ikai Lan > > Developer Programs Engineer, Google App Engine > > Blogger:http://googleappengine.blogspot.com > > Reddit:http://www.reddit.com/r/appengine > > Twitter:http://twitter.com/app_engine > > > On Thu, Oct 14, 2010 at 8:11 AM, Cain Wong <cw...@cloudsherpas.com> wrote: > > >> (THE FOLLOWING WAS ORIGINALLY POSTED IN THE GOOGLE GADGETS SUPPORT > >> FORUM) > > >> Steps to reproduce issue: > >> 1. Create a GAE Application that requires userservice.isUserLoggedIn() > >> to return true. If not redirect to userservice.createLoginURL(your- > >> app-url) > >> 2. Add an iFrame or similar gadget to a Google Sites page. Set your > >> GAE app as the content URL. The site should be on a Google Apps > >> domain so that a Google Apps user must be logged in to access the > >> site. > >> 3. Access the page with Internet Explorer (I've been testing with > >> version 8) > > >> Expected output: > >> The hopeful expected output would be that the GAE app would > >> immediately recognize that the user is logged in, and show its > >> content. However, the workflow that seems to occur with Firefox and > >> Chrome is as follows (and good enough for my purpose): > >> 1. The user logs in to Google Apps before accessing the site. > >> 2. The Sites page loads. > >> 3. The gadget loads, and subsequently loads the GAE app. > >> 4. The GAE app determines that the user is NOT logged in, and > >> redirects the user to the generated login URL. > >> 5. The resulting login URL pages recognizes that the user is already > >> logged in, and redirects back to the GAE app > >> 6. The GAE app now recognizes the user, and displays its content in > >> the gadget's iframe. > > >> Actual results: > >> With IE, the above workflow all seems to function the same with 2 > >> exceptions: > >> 1. The redirection to the login page and back seem to be slower, so > >> that the login page is actually displayed in the gadget iframe for a > >> brief moment. > >> 2. Upon redirecting back to the GAE app, the app breaks out of the > >> iframe filling the entire browser window. > > >> Any advice on how to prevent number 2 would be very helpful. Also, > >> if anyone can advise on a way to have a GAE app's Userservice > >> immediately recognize that the user is logged in without needing to do > >> the login url loop would be even more helpful. > > >> RESPONSE IN GOOGLE GADGETS FORUM: > >> "The IE-specific issues are going to be related to App Engine and not > >> gadgets, so I'd suggest asking this question in the App Engine forum. > >> There are most likely headers being sent during App Engine > >> authentication that direct some browsers (notably IE) to break out of > >> frames. The App Engine team would know better than I if there are ways > >> to mitigate this in certain contexts." > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Google App Engine" group. > >> To post to this group, send email to google-appeng...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> google-appengine+unsubscr...@googlegroups.com<google-appengine%2Bunsubscrib > >> e...@googlegroups.com> > >> . > >> 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 google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
