Summary: | kwebkitpart forgets login after opening new tab on some websites | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kwebkitpart | Reporter: | gce.galotta |
Component: | general | Assignee: | webkit-devel |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | adawit |
Priority: | NOR | ||
Version: | 0.9.6 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
gce.galotta
2011-11-27 13:53:37 UTC
This is not a bug. It is one of those unfortunate issues of sites setup to serve both "http" and "https" access to the same resource. This can easily be duplicated here in KDE bugzilla as well. I can visit this very bug report with the following two urls: http://bugs.kde.org/show_bug.cgi?id=287689 https://bugs.kde.org/show_bug.cgi?id=287689 (SSL) Unless the site explicitly requests it (which almost never happens), the cookies received from the second "secure" URL will never be sent back when you visit the first URL even though the addresses are the same. This is done to protect secure cookies from being transmitted in non-secure manner. I am almost certain that is the issue you are encountering here. If you simply change the protocol of the URL of the newly opened tab to "https" instead of "http", it fixes the problem, right ? If it does, then the way to resolve this issue is to first login to the site before you start opening new threads so you won't into this issue. It's not the same issue. Both URLs are on http and it works as long as i stay in this one window but as soon as right-click on a link "Open in new tab/new window" i get the "please login" window. But only in those two URLs up to know. (In reply to comment #2) > It's not the same issue. Both URLs are on http and it works as long as i stay > in this one window but as soon as right-click on a link "Open in new tab/new > window" i get the "please login" window. > But only in those two URLs up to know. I cannot reproduce this then. Can you please outline step by step how to reproduce this than the steps you provided above ? I did the following: 1.) I went to www.swtor.com 2.) Clicked on "Community->Forums". 3.) Clicked on the "News and Announcements" thread. 4.) Right clicked on several of those threads and selected "Open in New tab". Hmm... Perhaps I need to create an account and login first ? BTW, what version of kwebkitpart are you using ? Can you please update the version number in this bug report ? Yes, an account is neccessary. At the Forum www.schockwellenreiter.biz there is (should) a guest-account be displayed (for roleplay reasons): Un: Tell Pw: helvetia This User can post nothing. I forgot, your outlined steps are correct. With an account they should work. Webkitkpart is 0.9.6, i think. At least in the Softwaremanagement. (In reply to comment #4) > Yes, an account is neccessary. At the Forum www.schockwellenreiter.biz there is > (should) a guest-account be displayed (for roleplay reasons): > Un: Tell > Pw: helvetia > This User can post nothing. Okay, now I can reproduce what you are saying using not only the latest kwebkitpart, but also other QtWebKit based browsers such as Arora and reKonq. Also the QtWebKit test browser, QtTestBrowser seems to have the same issue. Out of curiosity I checked konqueror+khtml and that combination works just fine. That got me even more curious so I looked into differences between the HTTP headers sent when the two browser engines were used. From what I can tell the bug seems to be caused by the fact that the sites you mentioned require the "Referer" HTTP header to work properly. Unfortunately, QtWebKit does not seem to send that header when opening a URL in a new window. It does send it if you just click on the link. As such, this is a bug that needs to be reproted upstream. Alright, i will open a bugreport upstream (Qt). Thanks for your help. What Status should i set for this bug now? (In reply to comment #7) > Alright, i will open a bugreport upstream (Qt). Thanks for your help. Actually you should open a ticket against QtWebKit. See http://trac.webkit.org/wiki/QtWebKitBugs > What Status should i set for this bug now? Once you open the ticket against QtWebKit, please put the URL for the upstream ticket in this bug report and close it with RESOLVED/UPSTREAM status. |