Option to initiate Session API with JS

Unless I'm missing something, setting $create = FALSE will resolve the issue. If a site needs more control of when sessions are created, that's what the parameter is for. Perhaps flag can make that configurable? I'm also open to how session api itself might resolve this issue, but I don't have any ideas offhand.

I've confirmed that Session API is the root of the problem in #1468984: Flags deactivates page cache in combination with session_api module. Session API's use of the $_SESSION variable completely eliminates the purpose of this module. If we wanted to start a normal PHP session, you wouldn't have any purpose for Session API since a session ID is generated already once you put something in $_SESSION. The added effect of using $_SESSION is that the page cache is disabled.

What Flag module expects from Session API is that it will generate a numeric session ID without starting a normal PHP session.

Note that this problem is only apparent in Flag when using a non-global flag. Since Flag doesn't need a Session ID for global flags. It's simple enough to just enable the "bookmarks" flag that comes with the module for anonymous users to reproduce the problem.

This might do the trick. It should populate the $_COOKIE variable so that Session API can do its check.

Hello,
I applied this patch to dev version 7x1x dev. I had to set cookie time less because after clearing the cache in drupal, tha changes were visible after cookie expiration.
Hovewer, this is working so far with anonymous users and cache enabled.
Thank you.

Patch in #6 seems to be clean and sensible and works as expected for me with latest releases of Flag and Session API.

It's possible to port this patch also for 6.x-1.x module version?

Best,
hachreak

I am guessing this hasnt been commmited, I am hving issues with pages with user specific flags rendering no cache.

Big thanks @quicksketch! #6 works also with https://drupal.org/project/drupalchat

seems to work for me to.

Thanks for all the confirmations guys! I feel like this patch may need explanation as to how it works in order to be accepted by the maintainer.

+function session_api_init() {
+  // Set a cookie via JavaScript to check if anonymous users support cookies.
+  if (user_is_anonymous()) {
+    drupal_add_js("document.cookie = 'session_api_available=1; path=/';", array('type' => 'inline'));
+  }
 }

What this code is doing is setting a cookie via JavaScript. Why JavaScript instead of just setting a value in $_SESSION, $_COOKIE or setcookie()? Because if you set a value using any of those methods it requires sending a Set-Cookie HTTP Header to the client from Drupal. Using this header will disable all caching, because the user's browser is the intended recipient of the header.

So by using JavaScript instead, we can serve the exact same page to all anonymous users. The cookie will be set by JavaScript once the page has been loaded, and subsequent requests sent by the user will set the value in the $_COOKIE variable.

+1

Are we able to get some movement on this jhedstrom?

+++ b/session_api.module
@@ -8,20 +8,20 @@
+  // Set a cookie via JavaScript to check if anonymous users support cookies.

Perhaps you can include your explanation for using Javascript to set a cookie here.

+++ b/session_api.module
@@ -8,20 +8,20 @@
+    drupal_add_js("document.cookie = 'session_api_available=1; path=/';", array('type' => 'inline'));

Is the path correct when Drupal is installed in a subfolder?

Also, this patch needs to be rerolled against -dev and it causes a test failure.

Re-roll

This should do it. I'm just not exactly sure what "fooling session_api_get_sid()" was supposed to do.

+++ b/tests/session_api_test.module
@@ -24,6 +23,9 @@ function session_api_test_menu() {
+  // Make sure Session API thinks the client supports cookies.
+  $_COOKIE = array('session_api_test' => 'test');
+

The problem here is that cURL doesn't support JavaScript, so the cookie won't actually be set client-side and re-used for the next request. This should be done more elegantly.

Also this exposes an issue with this solution: clients that have JavaScript disabled won't be compatible with Session API. While that may be rare, it would be better to make the cookie initialization method configurable.

This should be an option as mentioned. I'm just wondering if it would also make sense to allow for "lazy-initializing" the session with JS, as currently happens with the Set-Cookie header.

Pros of using JS in the way proposed:

• Keeps pages for anonymous users cachable
• Starting the session after the first page load would reduce the chance of the bad UX where Session API is unavailable at first.

Cons:

• Doesn't degrade gracefully as it requires JS to work

Altered formatting for issue's queue link.

In my opinion, making session api works with anonymous users cachable would be great. I guess that most Drupal site use cachable page in order to earn performance. So it's would be a very good feature.

For people who disable JS, i guess session api won't be the first problem, but all "jQuery package" that almost all developpers use in their website.

It would be conveniant to have the cookie initialization method configurable (#22) with two options :

- Set the cookie through Javascript (works with anonymous user on cachable page)
- Set the cookie through the server

Before applied the patch, i have the similar issue which is when the 'bookmark flag' is flagged by an anonymous user, all the pages(fresh pages, havent been saved by boost module) i visited after it will not be saved by the boost.

After applied the patch, all the pages will be saved by the boost. But i have a problem here, the page with flagged(bookmarked) status is always showing 'bookmarked' for all the anonymous users who visited the cached page, even another anonymous user unflagged it.

I've no idea how to update the flag status alone, any ideas?