Re: [PATCH] Don't force gtkmozembed in the Facebook module

["John Stowers" <john stowers gmail com>]

On Sat, Mar 15, 2008 at 5:11 PM, Alexandre <airmind gmail com> wrote:

I like the idea of the external browser, because sometimes the user is already logged in, and only has to authorize or something else. This happens on Flickr for instance.

I don't agree. Let me explain. There are basically two types of sites, ones that make you log in all the time (box.net, facebook), and ones that make you log in once (Flickr).

For those sites that make you log in once, I dont think its too much effort to ask the user to log in again, after all, its only once.

If sites make you log in all the time, then I am interested in making that experience enjoyable and easy. Its only possible to do that consistently with a built in browser approach.

So in the end its a compromise. I think the best compromise is to make the common case the best, with the smallest amount of code.

Thoughts?

John

The only other (crappy) solution, that I can think of, is to run the system browser using a mechanism other than the webbrowser module so we can watch the process and then instruct the user to close the browser instance after they've granted or denied access.

There is no reliable way to create a blocking webbrowser call. I looked for a really really long time into how to do this sensibly, to no avail. webbrowser and xdg-open and gnomevfs all behave differently depending on whether
1) The browser is already running somewhere
2) The user has selected to 'always open new links in tabs'
3) The phase of the moon.

I really hope we can get gtkmoxembed to stop segfaulting, the built in login browser is a lot more pleasant experience!

This is just an idea I got from MusicBrainz. It runs a very small server on some port (probably an http server), opens the user browser with a page and the port as a parameter, then that port is called from within that page.
For this to work in our situation, it could go into a page hosted in the Conduit server, or a page served locally from Conduit, showing a message to close that page after authentication and a frame with the Facebook login page. Some _javascript_ code could contact the port when the page is closed to tell Conduit that authentication is over. There are drawbacks, but could be a workaround.
Maybe security could be an issue here, because this page could be hijacked and the login information stolen by someone else.
What do you think?

--
Alexandre Rosenfeld

EngComp 06 - USP São Carlos