About sessions and AHAH forms using iframe canvas
| Project: | Drupal for Facebook |
| Version: | 6.x-2.x-dev |
| Component: | Canvas Pages |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
I am testing this awesome FB framework for a iframe canvas application, and I am in the middle of some inconsistencies.
I have the iframe canvas working fine, I can see any node from the drupal site with js in pages working (js was the reason to use iframe instead FBML canvas),
but all the problems start with the form and the session_id used in the token for security.
When the form is shown the first time, then is executed with fb_cb/x/xxxxx for session_id and session_name, but next time is executed with a different ones:
>in the case you have another fb_connect open with the drupal server (in the same browser): with fb_connect/xxxx for session_id and for session_name SESSxxxxxx,
>but if you don't have any fb connect session then session_id is 0 and session_name is still the same SESSxxxx
I have read all the documentation and code in fb_session.inc in order to follow the logic for the application and to understand the fb behavior. Even I have seen all the code in the fb_connect and fb_canvas modules in order to support forms tough it seems that fb_connect_exit and the FB_OP_EXIT are not yet implemented.
So here I come across with many questions about the different options to try fixing that behavior:
If I force to use always the same session_id structure, then forms work fine as it was supposed to be.
Analyzing the different scenarios that you set in the code then I found that we would need to review them and check if some of them are really valid. I know that the module has to work with FBML canvas and the FB Connect configuration, not only iframe canvas applications. I would love the configuration where sessions are different from different fb applications and fb_connect sessions, but it seems a bit hard to get, at least for the forms.
What would it be your best option:
- try to change the #cache_token for any form using form_alter, with a new calculated token depending of the new session_id, regarding that first one is always calculated with the fb_cb/x/xxxx format and later is accessed with session_id 0 or fb_connect/xxxx
- or unify session_id formats for non session_id from fb and fb_connect format when usgin fb connect
I would like to help on this.
I attach the fb_session.inc with a coder restyling. I believe that if this so big and complex module would have a more drupalish code style, it would help to have more people using and testing it.
In the last part of the file, where it is evaluating the option with no sessions from facebook, the if and elseif clauses are the same, maybe it should be unified in the first if.
| Attachment | Size |
|---|---|
| fb_session.inc_.txt | 6.91 KB |
#1
patch file
#2
Explaining again the session_id format:
First time the form is read format is fb_canvas_x_XXXXXXXX
Next time:
- If browser has another session with a direct fb_connect session, then in iframe canvas session_id is fb_connect_XXXXXXXX
- if there is no other session open, then session_id is 0
#3
When I first implemented and tested iframe apps, facebook connect did not even exist. I haven't tested combining the two, iframe canvas pages and connect. But I can tell it's going to be a big fat mess.
Some things to keep in mind...
There are two ways to implement canvas pages, iframe or FBML. And there is also the combination of the two. That is part of the page is FBML and part is iframe using
<fb:iframe>markup. In this case when the two are combined, it is important that the two requests (one returns FBML and the other returns iframe markup) share the same session on Drupal.It's possible to implement both canvas pages and HTML pages with fb connect. So for example, http://apps.facebook.com/drupalforfacebook is a canvas page, while http://drupalforfacebook.org is HTML with Connect enabled. It is important that when a single browser visits these two pages, there are two different sessions as far as Drupal is concerned.
When serving FBML canvas pages, Drupal cannot set cookies. That's why fb_settings.inc relies on some of the parameters facebook passes in, in place of cookies.
When implementing FB Connect, Drupal must honor cookies which facebook has set. Facebook's cookies control the session instead of Drupal's normal cookies. Again code in fb_settings.inc handles this.
I worry that it will be tricky to support all the cases I'd like. It should work if a single drupal implements both Canvas pages with embedded iframes, AND HTML pages with connect. The embedded iframes should share session with the FBML canvas pages, and not share session with the HTML pages.
Hmmmm..... thought provoking....
#4
I am puzzling myself trying to fool the cache_token hash. I got to replace the form in cache with a new token using the right session_id, but this is done with a form_alter and then it is too late to have the form evaluated with the tampered values.
So trying to "adapt" form tokens to the running session seems it's going to be hard. Forms are the only part that are sensible to sessions and as you have told it is a mess of different combinations of sessions_id depending of having FBML canvas, iFrame canvas with/with out connect sessions against the same server, and even worst with different applications in the same box.
In fact, using iframes into an FBML we will have the same issue with forms as the initial connection from facebook it is always different from next user interaction with the page.
Maybe we should avoid fighting against facebook and try to use the same session structure it uses, though we have to sacrifice some nice features, that probably never will be used effectively.
Anyway, I am going to test different session_id structures that help to have different sessions in different scenarios, or maybe there could be different configurations in the fb_settings that define the session behavior depending of the complexity of the installation. As somebody told in other issue, most people just need fb_connect features and focusing on this main use case we could need to reinforce that part or configuration. But I agree that have the option to have a drupal page running in web and canvas is great. In my case because all the ajax/ahah forms I am running I need the iframe canvas set up, and forcing the right session_id with the fb_connect_xxxx setup works great in canvas and web connect even there is no way to isolate both sessions when using the same browser.
I don't know if using different session_name could help on this, do you know this?
#5
Don't try to change the token with form_alters or techniques like that. The problem is that the session is changing. Working around the form tokens will just mask the real problem.
Use the fb_devel block to see the session id and what the session contains. I recommend adding the block to your FBML and to the HTML iframe within it. If you ever see different session ids between the two, there is a problem.
Is your iframe theme calling fb_canvas_process()? See the last lines of fb_fbml_page() and emulate what is done there. (This is sort of a hack that can go away in D7 when urls can be altered. At least that is my hope.)
View the source of your iframe, where the form is displayed. Does the form action have "fb_cb/NNNN/" in it? Also view the properties of the iframe, does the url have "fb_cb/NNNN/" in it? It might be that the form action needs to have that but it is not getting there.
#6
I am using the fb_fbml theme with the required fb_canvas_process(), but with the page.tpl.php adapted for a iframe (by the way, the iframe.tpl.php is not loaded because fb_fbml_process() override the template variable from fb_fbml_preprocess() ).
In fact, I don't have problems with the url rewriting (I even added a condition in the fb_settings.inc to add and additional $config['admin_theme'] for iframe canvas, I sent a patch with this)
So it is a iframe facebook application without neither fbml nor fb:iframe on it. (I a different tests, I even have some testing pages, in iframe canvas, with a content of fb:serverfbml with fb:iframe that shows another fb iframe content into the iframe canvas, cool!)
For debugging sessions, I can't just use fb_devel (that I was using at the beginning) because first access from facebook it is different from next actions or updates in forms.
For testing I have created a form that register in a global variable the session_id, session_name, _request and other variables. This form has a ahah variable that process a function that update a section from the form, using #ahah, with the dpm output from the same variables and then there is where I can check the session_id's been used at the generation and at the ahah update. So tjhe form actions are going to the right urls.
There is where I found the session_id's combination that I explained before.
Let me explain again the combinations with fb_connect/iframe canvas with same fb application,
>using only a fb_connect direct access to the application using the direct drupal web (no facebook iframe canvas application open):
session_id: b7e112bd007436cd899a9065caa3xxxx
session_name: SESS19fbb177ef61a6278ab1e5e23548xxxx
both the same in form generation and ahah action.
Form is working fine because is using user_id => 0
>opening session in fb and using the iframe canvas application:
Initial session when creating the form:
session_id: fb_canvas_1_4e9a6d34ccf701540761bb2d-74041xxxx
session_name: fb_canvas_1_SESS19fbb177ef61a6278abxxxx
session when sending the form:
session_id: fb_connect_4e9a6d34ccf701540761bb2d-7404xxxx
session_name: SESS19fbb177ef61a6278ab1e5e23548xxxx
As you guess the form is not accepted because validation errors due to the cache_token, by the way user_id is still 0
If I updated twice the browser with the fb connect on it , then it detects the open session in the facebook canvas and shows me the
fb user logged in
On this case the session_id and session_name are the same than second case before when the form is created and sent (obviously, it is a direct web access)
If I change the logic in fb_session.inc to use a session_id format as fb_connect_ instead the fb_canvas_1_ then the forms token validation work,
as they are using always the same session_id's
Let me know if I can send you any test to get more clues,
but the issue is the session_id's mix between first access and next action sending.
#7
Finally I got some conclusions and a solution.
The problem with forms, in iframe canvas, only happen when using AHAH in forms, because the drupal ahah js is sending the form fields using a different session_id from the session in the iframe canvas.
Any other form sent directly from the web session uses the same session_id with the format fb_canvas_x_xxxxxxxx so it never has authentication errors because unmatched tokens.
The second issue is that depending of you use in the same browser a connect session with facebook and a facebook application or just a facebook application, the session_id is different for sending the ahah form. In the first case the session_id is the same from the fb_connect (fb_connect_xxxxxxx) and in the second there is a standard session (xxxxxxxx), so the solution need to cover both cases.
The solution that I found needs to use the fb forms module to adapt the ahah forms to the fb iframe canvas ( This module already it is doing some kind of adaptation for FBML canvas forms) and pass this values to the fb_session.inc in order to handle this conditions.
On this side, I found that for first case we have cookies for the existing session, and it could be extracted from the $_COOKIE in the same way that the fb_session.inc already do for other conditions, but for the second case there are no cookies, to get the session_id. That is because we need to use the fb_form module to add the session_id from the canvas session only when using iframe and the form has a #ahah type field. This session_id goes in a hidden form field that is sent together with the ahah form and read from the $_REQUEST variable in the fb_session.inc.
I attach:
> patch for fb_form.module that adds the session_id in a hidden form in the case of iframe canvas and AHAH
> patch for fb_sessions.inc to support the iframe canvas AHAH sessions
> patch with previous iframe canvas AHAH support plus coder module styling
> patch for just coder style for fb_settings.inc
#8
#9
Thanks for working on this, and submitting patches. However I don't think that's the right direction.
More likely, the URL used by the AHAH should have something in it to let fb_session.inc know what's going on. I wonder, do those URLs contain the "fb_cb/NNN" prefix? (They should. If not, the URLs are not being rewritten by custom_url_rewrite...)
I had to workaround an issue with Safari not settings cookies in iframes. To do so I made fb_session.inc honor a variable "fb_session_cookieless_iframe". Try setting that to TRUE in your settings.php before including fb_settings.inc. I'm curious whether that will work in this case.
#10
I already tried to set the fb_session_cokieless_iframe to test that condition, and it was the same.
The urls are working always fine using the fb_cb/x/xxx format for any answer even the ahah js is doing it so, you can check it seeing the js settings in the html with the right values for the ahah js.
For the case where you have another connect session you can read the session_id from the cookies without problems, but for the second case with only a fb application it doesn't work, that is because I finally removed that piece of code because once you have the values in the hidden form field it doesn't mind too much and it is faster probably.
Please let me know what address take to solve that, I decided to move into the iframe canvas option because once you have set the css with the same facebook style you have all the drupal power in fb application directly and in my case using ajax/ahah was important to improve the UX. But this problem with ahah forms is really a PITA. I know that this is a workaround to the problem in terms that the problem could be into the drupal ahah.js or even in the jQuery, but I don't guess that could be easier to fix that in the core and more when this is my only known case where drupal could run into an iframe.
#11
I am not alone with this issue, it is a kind of "known" issue that seems happen using ajax or even with in the facebook api
http://forum.developers.facebook.com/viewtopic.php?pid=169372
http://judebert.com/progress/archives/366-Facebook-Development-The-PHP-C...
http://wiki.developers.facebook.com/index.php/Your_callback_page_and_you
It could be related with with P3P:
http://drupal.org/node/166273
http://viralpatel.net/blogs/2008/12/how-to-set-third-party-cookies-with-...
But it is not the case here.
It is just about iframes, ajax and session_id's, and the Drupal form API that wisely manage the form security. (http://api.lullabot.com/form_get_cache)
The failing drupal token validation condition is when the user has a session (with other direct fb connect to the web hosting the fb application) and the session doesn't math when validating form tokens( from the ajaxified iframe canvas). The other drupal token validation alternative is when using anonymous users (that it is the case when the user is not logged in the drupal application and only with fb canvas).
So, if you want to have ajax in fb iframe application you can't have the user with Fb connect.
Then I come across with the use of different Fb applications. I mean a Drupal fb application for fb connect and another Drupal fb application for the fb iframe canvas, but this doesn't work either,
because the Drupal FB always take the session from facebook session and the facebook session id it is the same in both.
Solutions:
- a workaround as the patch proposed before that could arise security questions (I don't think as you are using this ajax form into an already validated and secure facebook session, you could only tamper your own forms not others ones. So it would require validated user facebook applications. And probably more care in your callback function to handle this returned info with the required doubts)
- not to have a fb_connect on the same server (multi-site installations and not shared sessions?)
- override drupal form_get_cache() in your AHAH callback function and use this information with all the extra strength security check-ins in your ahah callback function (you could not use the _form_validate or form_submit because it would fail)
So I guess that this issue will go to the postponed or won't fix category quickly.
Anybody else finding this issue would have the chance to take decisions with the proposed workarounds.
Dave, do you know about other options?
#12
New round with this issue.
I changed the approach using cookies instead of the form to pass the session id.
That is only when using iframe canvas and ahah/ajax forms, because the sessions id's are different in both sessions.
With Firefox you can save a cookie with the original session_id (cookies are saved with a duration of 1 day) and then the fb_session.inc, if it can't find the session in the url or in the existing sessions, can use that cookie to set the session id.
As I explained before that is only needed with iframe canvas and ahah/sessions and not other fb_connect open in the same browser.
With IE is the same but you need to add the p3p the header to allow accepting cookies from different iframe/sessions and it works on the same way.
But with Safari there is a known issue that affects to everybody using iframe with facebook, because it doesn't accept cookies from different iframes.
On this case there is not other way to fix it that using the form to pass the session_id ( remember, only with safari and ahah forms).
It is likely the same that using the fb_session_cookieless_iframe setting but passing the session_id in the html/form instead that in the url.
It could be changed to use the same _fb_settings_parse(FB_SETTINGS_SESSION_KEY) function if it was better to use url passing than form passing information.
But I have seen that the url processing of the /fb_sess/xxxx/fb_cb/x/xxxx is not already done, only it is used in the fb_session.inc to get the session_id but there is a 404 error because the real url destination is not set.
It is a little step, but I was trying to implement some tricks to solve the Safari cookies security issue but without any luck on this.
Why do you prefer using the url to pass the session_id on this extreme cases better than using a form field for this? I wouldn't mind to addapt that case if you consider it better.
#13
I believe if you set this cookie, it will change the session if the visitors goes directly to the web server, instead of the facebook app.
If this technique works, the fb_session_cookieless_iframe hack should work just as well. I suspect the ahah URLs are not being rewritten. Perhaps that's all that needs fixing here???
#14
Hi Dave,
I have checked the fb_session_cookieless_iframe option, but the new rewritten url send to fb_sess/xxxxxxxxxxxxxxxxx/fb_cb/1/wherever, and this address doesn't exist because the program only is redirecting the fb_cb/1/wherever url's.
For the url's:
I can browse all my drupal server without problems in the iframe_canvas.
When I see the form with the AHAH in the iframe_canvas I get this
q (String, 14 characters ) fb_cb/1/ticket and session fb_canvas_1_4e9a6d34ccf701540761bb2d-740414808
If I check the ahah and I show variables into the replaced div I can see:
q (String, 17 characters ) fb_cb/1/ticket/js, and session fb_canvas_1_4e9a6d34ccf701540761bb2d-740414808 (that's because the patch in other case it would be empty)
Then I have discarded any issue with url rewrite, that it's working fine, in other case it would be impossible to browse the drupal site from the fb canvas application.
Now I will test the sessions with this patch in different scenarios, hopefully it could give you some information and check how it works:
If I go directly to the web server and check the same form (going to /ticket) the ahah works again. And I get
only the form-> session: fb_connect_4e9a6d34ccf701540761bb2d-740414808 (I have a fb_connect on it, connect and in the same browser than the direct fb application)
if I click the ahah: -> session: fb_connect_4e9a6d34ccf701540761bb2d-740414808 (Here the patch doesn't work because the conditions)
Now I close the fb session and the fb connect session, and I open a new browser (IE this case)
Without fb_connect connect neither other tab with any facebook session:
form session: b4586be0109e0df71e8dc82cae7a166f
ahah session: b4586be0109e0df71e8dc82cae7a166f
Close this tab and I open a fb session into the fb canvas application:
Form: fb_canvas_1_4e9a6d34ccf701540761bb2d-740414808
ahah: fb_canvas_1_4e9a6d34ccf701540761bb2d-740414808
In other tab I open the main web and start the fb_connect with the login my picturem the log-off option and all the stuff
form:fb_connect_4e9a6d34ccf701540761bb2d-740414808
ahah: fb_connect_4e9a6d34ccf701540761bb2d-740414808
At the same time in the fb application:
form fb_canvas_1_4e9a6d34ccf701540761bb2d-740414808
ahah fb_canvas_1_4e9a6d34ccf701540761bb2d-740414808
All this is with the patch, if I don't use the path is totally and wrong between session in form and ahah answer with the form token validation errors.
If I log-off from facebook the fb_connect get closed as well and then session is 918919654d04327d74dad754231cd7b4 again.
The session in the fb_connect and in the fb application in the same browser are always the same as it share the same fb session cookies, this because you can get he session from cookies in the fb_session.inc,
but in other case is imposible to find anything in the cookies
Now a new test, I add a different fb connect from the fb application, I mean two different facebook application, one with canvas (and the connect) and other new one just with the connect without canvas:
Direct access without any fb session open:
form: session 918919654d04327d74dad754231cd7b4
ahah: session 918919654d04327d74dad754231cd7b4
I click in the fb connect and login with facebook
form: session: fb_connect_3.yfEweD_p6LAYmYHWPm58Ag__.86400.1257451200-740414808
ahah: session fb_connect_3.yfEweD_p6LAYmYHWPm58Ag__.86400.1257451200-740414808
I open the fb session in other tab and I go the the fb iframe canvas application
form: session: fb_canvas_1_4e9a6d34ccf701540761bb2d-740414808
ahah: session: fb_canvas_1_4e9a6d34ccf701540761bb2d-740414808
As you can guess the only fb conect application is the node 3 and the iframe canvas is the uid 1
Now I came back to the fb connect I a get:
form: sesison : fb_connect_4e9a6d34ccf701540761bb2d-740414808
ahah: session: fb_connect_4e9a6d34ccf701540761bb2d-740414808
As you can see once I open a facebook application then this session override the fb_connect in the other one,
so as I explained in other posts, it is really hard to have different drupal fb applications in the same server, and at the same in the same browser.
If you have different fb application (fb connect and fb canvas application) when you close the facebook session the direct connect get crazy reloading,
so if you want to have direct web connect and fb application canvas at the same time they need to be the same fb application.
Hopefully this could help you to understand the situation, I have tried to tune the patch to the only cases that is failing, with cookies when is possible
and when is safari, with the same security concerns that using fb_session_cookieless_iframe settings (if this configuration worked with the url's).
I guess that when more people start using the Drupal FB Framework with iframe canvas applications, then they could help with more tests and validations.
That is what happen when you have a general module that cope with all the facebook configurations and features,
that it is the best of this module but at the same time the most difficult, because there are many combinations to test (and damned different browsers).
#15
I finally had some time to look into this. It's a pain to reproduce.
In doing so, I found a couple bugs. First in the fb_fbml theme's iframe handing (which you're not using, but I am). And then in the cookieless iframe feature. When I solved that, I found it worked as I expected it to. That is, with the cookieless iframe setting enabled, the ahah calls shared the same session and worked as expected. Without that, they had a different session.
So when I get some more time (tomorrow) I'll clean up these fixes and check in a patch. At that point, you'll be able to use fb_session_cookieless_iframe as a workaround.
I have a lot of hesitation around that as a solution. Something feels very wrong to me about embedding the session id in a url. From a security standpoint, I think its worse than embedding that value in a form. But I don't know much when it comes to security. And I can't think of another solution right now.
#16
Thank you for your comments, and I look forward to test your patches.
BTW, I am using the fb_fbml theme with iframes, but as I told at the beginning on this
issue the template iframe.tpl.php is overridden by the page.tpl.php, in the fb_fbml_page function.
I am working with an iframe canvas fb application, but at hte same time direct web access with fb_connect.
#17
I find myself unable to access CVS today.
cvs update: authorization failed: server cvs.drupal.org rejected access to /cvs/drupal-contrib for user yogadexNot sure if that's a temporary problem or due to a recent upgrade to my system. Not sure how I can fix it.
So for now I can't even do a cvs diff to get you a patch. Frustrating.
Yes you're right about the iframe.tpl.php not being used. A fix for FBML tabs broke that and because I was not working with any sites that used it, I did not notice until now. And I didn't catch that you pointed it out. Without that iframes will not include all the javascript necessary for AHAH.
#18
I created a new template for iframe using page.tpl.php, and loading all the required content from the existing iframe.tpl.php.
So the js is loaded right, I am using jQuery intensively into the iFrame with no problems at all.
#19
I just checked in this diff, so you can either apply the patch or get the latest module from CVS (or wait for the update to reach drupal.org).
This fixes the iframe.tpl.php issue. And makes its so setting
$conf['fb_session_cookieless_iframe'] = TRUE;in settings.php should make the combination of FBML, iframe, facebook connect and ahah function properly.Give that a try and let me know.
#20
Hi Dave,
sorry for my late answer, I was waiting to have some time to dedicate it to your patch on full time. So in the last days I was testing and upgrading my fb version to last devel version and,
I found that this patch made that now the ahah and the use of the fb_session_cookiless_iframe option work perfectly. In fact, I have discarded my proposed patch for your better solution.
(I even found that my patch had an issue when adding the session value only in ahah forms, the condition that was adding the form value with the session was not working fine).
But with that last changes (as I update the fb module to last dev version and trying to figure out where could be this new issue), I found a bug that I didn't have before:
if you are accessing the facebook application with anonymous user, then the first time you refresh any screen, you get in the iframe the application with the fb canvas theme but when you reload it, then you
have in the iframe the app with the web theme. It is always the same, reload and iframe theme, reload and web theme. But only with anonymous users not when the user has authorized the application.
I am testing this trying to find the possible bug.
I didn't open a new issue as I am not sure if this bug is only because this patch or following updates. But the rest of updates are not really related with session issue. This patch is the last change in the fb module that could be affecting the application in terms of sessions and theme selection.
Any idea?
#21
More clues:
-that happens with any browser (FF, IE, Chrome and Safari)
- Using the devel info:
devel info from fb canvas with the wrong web theme:
Page Status = Global fb instance is set (followed link in iframe, or handling a form).
fb_facebook_user =
fb_api_check_session() = Returned FALSE
local user = Guest
fb_get_fbu =
base_url = http://xxx.xxxxx.com
base_path = /
url() returns = /fb_cb/1/
$_REQUEST[q] is = fb_cb/1/fb_cb/1/devel
arg(0) is = node
arg(1) is = 821
session_id =
session_name = SESSxxxxxxxxxxxxx61a6278ab1e5e2354886a1
Devel info from fb canvas with the right iframe theme:
Page Status = Rendering iframe.
fb_facebook_user =
fb_api_check_session() = Returned FALSE
local user = Guest
fb_get_fbu =
base_url = http://xxx.xxxxxxxxxx.com
base_path = /
url() returns = /fb_cb/1/
$_REQUEST[q] is = fb_cb/1/devel
arg(0) is = node
arg(1) is = 821
session_id = fb_canvas_1_shared_session
session_name = fb_canvas_1_SESSxxxxxxxxxx1a6278ab1e5e2354886a1
#22
I am trying to debug fb modules where the url is changed adding the fb_cb/x/xxx to the url for requests coming from any fb canvas page, (the problem with anonymous users is that the fb_cb/x/ is added twice alternatively, so it could a fb variable detection issue)
But I also found that this happen when administering the drupal server (without canvas).
Dave, do I open a new issue or this bug is related with this one?
#23
I don't think its related. Better to open a new issue. Thanks.