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:
create an instance of URL:
const URL url (“https://” ACTIVATION_LINK “/unlock”);
call url.readEntireTextStream (false) to do a GET - the reply contains an “authenticity_token” which is associated with the current session.
create another instance of URL:
const URL url2 (“https://” ACTIVATION_LINK “/unlocks/log_and_unlock”);
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.
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.
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.
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.
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.
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.
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).