URL no longer keeps session context


#1

Hi, I recently updated to the latest GIT tip and the behaviour of the URL class seems to have changed since I last updated (over a year ago), which is breaking my app. Here is my scenario:

  1. create an instance of URL:
    const URL url (“https://” ACTIVATION_LINK “/unlock”);

  2. call url.readEntireTextStream (false) to do a GET - the reply contains an “authenticity_token” which is associated with the current session.

  3. create another instance of URL:
    const URL url2 (“https://” ACTIVATION_LINK “/unlocks/log_and_unlock”);

  4. call url2.withParameter (“authenticity_token”, _token).readEntireTextStream (true) to do a POST - using the token from step 2 to authenticate.

This used to work because juce_win32_Network.cpp was caching the connection. Now it seems to use a fresh connection each time, which invalidates my authenticity token in my web-app.

Any suggestions? Thanks.


#2

By the way, this is not an issue with my ‘production’ code. Fortunately I found it in testing before I released anything, so I’m not too stressed about it. Thanks. :slight_smile:


#3

FYI after reimplementing connection caching in juce_win32_Network.cpp, my problem still persisted. It turns out that all I needed to do to solve it was this:

replace DWORD flags = INTERNET_FLAG_RELOAD | INTERNET_FLAG_NO_CACHE_WRITE | INTERNET_FLAG_NO_COOKIES;
with this DWORD flags = INTERNET_FLAG_RELOAD | INTERNET_FLAG_NO_CACHE_WRITE;

to allow cookies. The connection caching wasn’t needed after all. Problem solved. :slight_smile:


#4

It’s really not a good idea to write code that depends on such a specific behaviour of the OS’s http stack. My URL classes make absolutely no promises about cookies, and they certainly won’t work on all platforms… I wouldn’t even say that they’re likely to work the way you want on all Windows machines. Better to avoid them altogether and build a more explicit way to communicate with your server.


#5

OK thanks, I’ll look for an alternative. By the way, this authenticity_token is the standard way for Ruby on Rails web apps to avoid Cross Site Scripting attacks.


#6

Thinking about it some more, this URL doesn’t need protection from XSS attacks as the user is not logged in at this point, so I can just ditch the authenticity token requirement on the server side and leave cookies turned off. Thanks.


#7

seriously, INTERNET_FLAG_NO_COOKIES should be removed from the flag. If not, the behavior is not consistent on other platform (Mac OS X, I didn’t test Linux).


#8

No, like I said, it’s not consistent across platforms! On linux it definitely won’t use cookies, so the only way I could make it consistent would to disable it on all platforms. Basically, don’t rely on it!