frame/object control with login
117 views
Skip to first unread message
Tony Reyelts
Nov 2, 2009, 4:36:06 PM11/2/09
to Google App Engine
I apologize if I'm posting to the wrong place, I don't know if this is
a basic HTML question, a Python question, a GAE question, or some
combination of the set...
Since we can't have much impact on the use login window for Google App
Engine (ie to change the language or add an image), I'm looking at
embedding the login page, like so:
from google.appengine.ext import webapp
from google.appengine.api import users
class main(webapp.RequestHandler):
def get(self):
user = users.get_current_user()
if user == None:
self.response.out.write('<html>\n<body>\n')
self.response.out.write('<p>My intro text</p>\n')
self.response.out.write('<hr>\n')
self.response.out.write('<object\n')
self.response.out.write(' data="' + users.create_login_url
(self.request.uri) + '"\n')
self.response.out.write(' type="text/html"\n')
self.response.out.write(' width=100% height=50%>\n')
self.response.out.write('</object>')
self.response.out.write('<hr>\n')
self.response.out.write('</body>\n</html>\n')
else:
self.response.out.write('<html>\n<body>\n')
self.response.out.write('<p>' + user.nickname() + 'is logged
in!</p>\n')
self.response.out.write('</body>\n</html>\n')
This works fine: I get "My intro text" at the top of the window
followed by a pane with the login. However, when I login, the result
("user is logged in") is written to the pane where the login occurred,
vs. replacing the whole window. I tried this with the older <iframe>,
and get the same result.
Is there a way to re-take over the complete window (ie make the frame
I created go away) on the redirect?
a basic HTML question, a Python question, a GAE question, or some
combination of the set...
Since we can't have much impact on the use login window for Google App
Engine (ie to change the language or add an image), I'm looking at
embedding the login page, like so:
from google.appengine.ext import webapp
from google.appengine.api import users
class main(webapp.RequestHandler):
def get(self):
user = users.get_current_user()
if user == None:
self.response.out.write('<html>\n<body>\n')
self.response.out.write('<p>My intro text</p>\n')
self.response.out.write('<hr>\n')
self.response.out.write('<object\n')
self.response.out.write(' data="' + users.create_login_url
(self.request.uri) + '"\n')
self.response.out.write(' type="text/html"\n')
self.response.out.write(' width=100% height=50%>\n')
self.response.out.write('</object>')
self.response.out.write('<hr>\n')
self.response.out.write('</body>\n</html>\n')
else:
self.response.out.write('<html>\n<body>\n')
self.response.out.write('<p>' + user.nickname() + 'is logged
in!</p>\n')
self.response.out.write('</body>\n</html>\n')
This works fine: I get "My intro text" at the top of the window
followed by a pane with the login. However, when I login, the result
("user is logged in") is written to the pane where the login occurred,
vs. replacing the whole window. I tried this with the older <iframe>,
and get the same result.
Is there a way to re-take over the complete window (ie make the frame
I created go away) on the redirect?
djidjadji
Nov 3, 2009, 7:47:32 PM11/3/09
to google-a...@googlegroups.com
How do you make sure that there is no impression of being phished?
I would not trust such a construct and leave the site.
2009/11/2 reyelts <rey...@gmail.com>:
I would not trust such a construct and leave the site.
2009/11/2 reyelts <rey...@gmail.com>:
Nick Johnson (Google)
Nov 4, 2009, 3:40:01 AM11/4/09
to google-a...@googlegroups.com
Hi,
Framing the login page is strongly discouraged, and may in fact be contrary to the TOS. The only way for the user to determine that a login page for a Google account is legitimate is to check if it's being served off the google.com domain, and this is not possible inside a frame.
-Nick Johnson
--
Nick Johnson, Developer Programs Engineer, App Engine
Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047
Nick Johnson, Developer Programs Engineer, App Engine
Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047
ryan baldwin
Nov 4, 2009, 1:44:51 PM11/4/09
to google-a...@googlegroups.com
Nick,
- ryan.
I think you're overestimating the proverbial "average user". In fact, in user testing our own application, users are almost unanimously tripped up when they are redirected to Google to login. We frequently heard the user say this:
"Okay, now I click here to login and... oh... why am I asked to login to Google?"
I'm just pointing this out so that we don't all get stuck in a belief set that may not be accurate. Personally, I think Google needs to come up with an API (whether it be javascript or otherwise) for AppEngine apps to authenticate users more naturally. It's very jarring and, dare I say, short sited to force all users of all apps away from an application to an unbranded login screen.
- ryan.
Joshua Smith
Nov 4, 2009, 2:06:55 PM11/4/09
to google-a...@googlegroups.com
+1.
We've abandoned using google's user authentication for exactly this reason. It confused the hell out of all our users.
When we started using google apps for our email, it started confusing the hell out of us.
-Joshua
Tony Reyelts
Nov 4, 2009, 2:34:06 PM11/4/09
to Google App Engine
I admit to not having been through all of the Java documentation on
http://code.google.com/appengine/docs/. I have, however, been through
the Python stuff extensively and never came across anything that
suggests "framing the login page is strongly discouraged". In fact,
some information on recommended HTML usage would be a very welcome
addition to the Google App Engine Docs.
I also was unable to find anything to suggest there was a problem with
the TOS. I'm not modifying anything from Google nor am I usurping or
reverse engineering or bypassing any Google interfaces. In fact, I am
trying desperately to use a Google interface as-is and in such a
manner as is not confusing to my user population.
The frame/object *is* being served from the google.com domain. I have
no desire to nor have I made any attempt to bypass that. Depending on
the browser, there are multiple ways of verifying the source of the
frame. For example, IE's "Properties" and Chrome's "Inspect Element"
clearly show the source address.
Finally, if you have alternatives to suggest, I welcome them. I'm just
trying to do what's best for my users while staying within the limits
of the tools you provide. As evidenced by other contributors to this
thread, you can see that I am not alone in this endeavor.
On Nov 4, 1:40 am, "Nick Johnson (Google)" <nick.john...@google.com>
wrote:
http://code.google.com/appengine/docs/. I have, however, been through
the Python stuff extensively and never came across anything that
suggests "framing the login page is strongly discouraged". In fact,
some information on recommended HTML usage would be a very welcome
addition to the Google App Engine Docs.
I also was unable to find anything to suggest there was a problem with
the TOS. I'm not modifying anything from Google nor am I usurping or
reverse engineering or bypassing any Google interfaces. In fact, I am
trying desperately to use a Google interface as-is and in such a
manner as is not confusing to my user population.
The frame/object *is* being served from the google.com domain. I have
no desire to nor have I made any attempt to bypass that. Depending on
the browser, there are multiple ways of verifying the source of the
frame. For example, IE's "Properties" and Chrome's "Inspect Element"
clearly show the source address.
Finally, if you have alternatives to suggest, I welcome them. I'm just
trying to do what's best for my users while staying within the limits
of the tools you provide. As evidenced by other contributors to this
thread, you can see that I am not alone in this endeavor.
On Nov 4, 1:40 am, "Nick Johnson (Google)" <nick.john...@google.com>
wrote:
Tony Reyelts
Nov 4, 2009, 2:44:30 PM11/4/09
to Google App Engine
I did find a rather ugly workaround. If imbed the login as an <iframe>
(not an <object>), I can use a bit of Javascript to reload the parent
page and make the <iframe> go away. To do this, I have the the login
redirect generates the following:
self.response.out.write('<html>\n')
self.response.out.write('<head>\n')
self.response.out.write('<script type="text/javascript">\n')
self.response.out.write('function test()\n')
self.response.out.write('{\n')
self.response.out.write(' if (self != parent)
parent.window.location.reload();\n')
self.response.out.write('}\n')
self.response.out.write('</script>\n')
self.response.out.write('</head>\n')
self.response.out.write('<body onload="test();">\n')
self.response.out.write('<p>Loading...</p>\n')
self.response.out.write('</body>\n')
self.response.out.write('</html>\n')
On the resulting reload, I can tell that someone is logged in
(users.get_current_user()) and then proceed as normal.
The same approach works fine for an <object> with Chrome and Firefox.
But it does not work with IE for some reason. It seems the resulting
"frame" (though we're using the <object> tag to generate it) isn't
built with same parent-child relationship as is done under Chrome and
Firefox. Consequently, with IE, the reload() only affects the frame,
not the window. So, I do have a working solution if I'm willing to
give up adhering to XHTML Strict.
(not an <object>), I can use a bit of Javascript to reload the parent
page and make the <iframe> go away. To do this, I have the the login
redirect generates the following:
self.response.out.write('<html>\n')
self.response.out.write('<head>\n')
self.response.out.write('<script type="text/javascript">\n')
self.response.out.write('function test()\n')
self.response.out.write('{\n')
self.response.out.write(' if (self != parent)
parent.window.location.reload();\n')
self.response.out.write('}\n')
self.response.out.write('</script>\n')
self.response.out.write('</head>\n')
self.response.out.write('<body onload="test();">\n')
self.response.out.write('<p>Loading...</p>\n')
self.response.out.write('</body>\n')
self.response.out.write('</html>\n')
On the resulting reload, I can tell that someone is logged in
(users.get_current_user()) and then proceed as normal.
The same approach works fine for an <object> with Chrome and Firefox.
But it does not work with IE for some reason. It seems the resulting
"frame" (though we're using the <object> tag to generate it) isn't
built with same parent-child relationship as is done under Chrome and
Firefox. Consequently, with IE, the reload() only affects the frame,
not the window. So, I do have a working solution if I'm willing to
give up adhering to XHTML Strict.
Devel63
Nov 5, 2009, 3:26:03 PM11/5/09
to Google App Engine
+ another 1
User testing showed the Google login experience to be extremely
confusing for users (so we switched to Facebook Connect ... don't get
me started on the problems with Facebook, but at least their Connect
Experience doesn't confuse users).
Would be wonderful if we could use our own custom look on the front-
end for a Google account, or if Google developed a similar awareness
as Facebook has done with Connect so that people understand what's
going on.
On Nov 4, 11:06 am, Joshua Smith <JoshuaESm...@charter.net> wrote:
> +1.
>
> We've abandoned using google's user authentication for exactly this
> reason. It confused the hell out of all our users.
>
> When we started using google apps for our email, it started confusing
> the hell out of us.
>
> -Joshua
>
> On Nov 4, 2009, at 1:44 PM, ryan baldwin wrote:
>
> > Nick,
>
> > I think you're overestimating the proverbial "average user". In
> > fact, in user testing our own application, users are almost
> > unanimously tripped up when they are redirected to Google to login.
> > We frequently heard the user say this:
>
> > "Okay, now I click here to login and... oh... why am I asked to
> > login to Google?"
>
> > I'm just pointing this out so that we don't all get stuck in a
> > belief set that may not be accurate. Personally, I think Google
> > needs to come up with an API (whether it be javascript or otherwise)
> > for AppEngine apps to authenticate users more naturally. It's very
> > jarring and, dare I say, short sited to force all users of all apps
> > away from an application to an unbranded login screen.
>
> > - ryan.
>
> > On Wed, Nov 4, 2009 at 2:40 AM, Nick Johnson (Google) <nick.john...@google.com
User testing showed the Google login experience to be extremely
confusing for users (so we switched to Facebook Connect ... don't get
me started on the problems with Facebook, but at least their Connect
Experience doesn't confuse users).
Would be wonderful if we could use our own custom look on the front-
end for a Google account, or if Google developed a similar awareness
as Facebook has done with Connect so that people understand what's
going on.
On Nov 4, 11:06 am, Joshua Smith <JoshuaESm...@charter.net> wrote:
> +1.
>
> We've abandoned using google's user authentication for exactly this
> reason. It confused the hell out of all our users.
>
> When we started using google apps for our email, it started confusing
> the hell out of us.
>
> -Joshua
>
> On Nov 4, 2009, at 1:44 PM, ryan baldwin wrote:
>
> > Nick,
>
> > I think you're overestimating the proverbial "average user". In
> > fact, in user testing our own application, users are almost
> > unanimously tripped up when they are redirected to Google to login.
> > We frequently heard the user say this:
>
> > "Okay, now I click here to login and... oh... why am I asked to
> > login to Google?"
>
> > I'm just pointing this out so that we don't all get stuck in a
> > belief set that may not be accurate. Personally, I think Google
> > needs to come up with an API (whether it be javascript or otherwise)
> > for AppEngine apps to authenticate users more naturally. It's very
> > jarring and, dare I say, short sited to force all users of all apps
> > away from an application to an unbranded login screen.
>
> > - ryan.
>
> > > wrote:
> > Hi,
>
> > Framing the login page is strongly discouraged, and may in fact be
> > contrary to the TOS. The only way for the user to determine that a
> > login page for a Google account is legitimate is to check if it's
> > being served off the google.com domain, and this is not possible
> > inside a frame.
>
> > -Nick Johnson
>
> > Hi,
>
> > Framing the login page is strongly discouraged, and may in fact be
> > contrary to the TOS. The only way for the user to determine that a
> > login page for a Google account is legitimate is to check if it's
> > being served off the google.com domain, and this is not possible
> > inside a frame.
>
> > -Nick Johnson
>
Scott Ellis
Nov 5, 2009, 6:13:49 PM11/5/09
to google-a...@googlegroups.com
The same issue creates a very difficult problem for iGoogle gadgets hosted within GAE apps that use google auth.
Nick Johnson (Google)
Nov 5, 2009, 6:28:24 PM11/5/09
to google-a...@googlegroups.com
On Wed, Nov 4, 2009 at 8:34 PM, reyelts <rey...@gmail.com> wrote:
I admit to not having been through all of the Java documentation on
http://code.google.com/appengine/docs/. I have, however, been through
the Python stuff extensively and never came across anything that
suggests "framing the login page is strongly discouraged". In fact,
some information on recommended HTML usage would be a very welcome
addition to the Google App Engine Docs.
I also was unable to find anything to suggest there was a problem with
the TOS. I'm not modifying anything from Google nor am I usurping or
reverse engineering or bypassing any Google interfaces. In fact, I am
trying desperately to use a Google interface as-is and in such a
manner as is not confusing to my user population.
The frame/object *is* being served from the google.com domain. I have
no desire to nor have I made any attempt to bypass that.
In your case, yes it is. However, there's no reliable visual cue to the user that this is the case, and thus no way for the user to easily tell your legitimate iframed login page from a Phishing site's fake iframed login form. For that reason, putting the login form in an iframe is very strongly discouraged - you're essentially teaching your users to be susceptible to phishing for their Google account details. For the same reason, it's extremely unlikely any API to allow you to take Google user credentials yourself will be offered.
Depending on
the browser, there are multiple ways of verifying the source of the
frame. For example, IE's "Properties" and Chrome's "Inspect Element"
clearly show the source address.
It would be unreasonable to expect even a 'power user' to do this on every login, let alone everyone else.
Finally, if you have alternatives to suggest, I welcome them.
How about showing the login form in a popup? That way, the google.com URL is fully visible, without navigating away from your site. This is the approach Google Friend Connect takes.
I'm just
trying to do what's best for my users while staying within the limits
of the tools you provide.
I would humbly point out that offering your users a login form that is a hallmark of phishing sites is not best for your users.
-Nick Johnson
mscwd01
Nov 23, 2009, 8:58:09 AM11/23/09
to Google App Engine
On Nov 5, 11:28 pm, "Nick Johnson (Google)" <nick.john...@google.com>
wrote:
> On Wed, Nov 4, 2009 at 8:34 PM, reyelts <reye...@gmail.com> wrote:
>
> For the same reason, it's extremely unlikely any API to allow you to take
> Google user credentials yourself will be offered.
Okay, this if fine I can understand you not wishing to let any website
>
> For the same reason, it's extremely unlikely any API to allow you to take
> Google user credentials yourself will be offered.
ask its users for their Google account details; however, you are
completely ignoring the problem. Why can you not meet us half way and
allow us to customise the default Google login page?
All we need, in addition to what is already on the sign in page, is
the following:
- Ability to place our site logo in a prominent position (so users can
see the login is still related to the site they wish to use)
- Ability to place a short message below the default Google text (i.e.
CompanyXYZ uses Google Accounts to login, after entering your details
you will be redirected back to CompanyXYZ's site)
- Thats all!
How hard can it be?
bFlood
Nov 23, 2009, 10:06:03 AM11/23/09
to Google App Engine
I agree with mscwd01, all we really need is a section for a logo/small
text description. The GAE app name/desc is already be placed on the
login page, couldn't you just add to this a small (scrubbed) html
template? I suppose you would need to host any images somewhere on
google.com but I can't imagine a small logo upload would be a major
problem
cheers
brian
text description. The GAE app name/desc is already be placed on the
login page, couldn't you just add to this a small (scrubbed) html
template? I suppose you would need to host any images somewhere on
google.com but I can't imagine a small logo upload would be a major
problem
cheers
brian
Reply all
Reply to author
Forward
0 new messages