Mickey schrieb: > I'm attempting to integrate with Facebook using the minifb.py API, so > what's going on is that I end up with a ID for the Facebook user, and > use that to create an User object in TG. I'd like to have that > identity hang around.
I'm using the same technique and the recipe to integrate a TG 1.1 app with a SQLAlchemy model with OpenID. Works perfectly. See http://code.google.com/p/tgopenidlogin/issues/detail?id=4 for the code. > If you know the recipe, one change I made was to make the exception > completely generic; the recipe calls for SQLObjectNotFound, and I was > actually getting a ValueError becase the visit key was not an int(). This ValueError was actually indicating an error in the recipe when used with an SQLObject identity model, due to a small but important difference between the SO and SA implementation of the VisitIdentity class: in SA the primary key is 'visit_key' but SO adds its own standard 'id' attribute as the primary key, which is an int, not a string. I'm not sure since when this is the case but in the current default identity model, VisitIdentity has a 'by_visit_key' class method. I changed the recipe in the wiki to use this method. > From the debug statements, I verify that the login works. In > subsequent controllers, identity is back to anonymous. Login works for the current requests, yes. But since the flawed recipe will always throw an exception for "model.VisitIdentity.get(visit_key)" with SQLObject and your change masks this, it will always create a new VisitIdentity, which is why login is lost on the next request. Lesson of the day: never suppress an exception you don't understand! > I was also logging the visit key, and that changes, which may be > because things originate with facebook servers, but it's an iFrame > application, so maybe the visit changes, and so identity can't > persist???? What do you mean by "things"? For the identity framework to function, all requests must transfer the visit_key as a cookie. If request are coming from your browser, everything should be ok. If your app also _receives_ requests from the Facebook servers, it depends on whether they contain the cookie, for the visit identit link to be maintained accross requests. If the visit key changes, this is an indication that the visit key is not transmitted/recognized, because when the visit key is not found, the visit framework will create a new one on each request. But I think the root of the problem is the one discussed above. Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
