Opened 10 years ago
Closed 9 years ago
#11236 closed bug (fixed)
Cannot log into secure site
Reported by: | vidrep | Owned by: | pulkomandy |
---|---|---|---|
Priority: | blocker | Milestone: | R1/beta1 |
Component: | Applications/WebPositive | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
I cannot log into the TD website using Web+ 1.4.4. It either returns to the log in page, or tells me "session expired".
Attachments (2)
Change History (20)
comment:1 by , 10 years ago
Component: | - General → Applications/WebPositive |
---|---|
Owner: | changed from | to
by , 10 years ago
comment:2 by , 10 years ago
comment:3 by , 10 years ago
Problem still present in latest nightly hrev48242. I can log in with alpha 4.1.
comment:4 by , 10 years ago
Tried again today with Webkit 1.4.10. Webpositive still cannot log into TD Canada Trust easyweb on-line banking - it always returns to the log in screen or displays an "session expired" error message. The old Webkit bundled with Alpha 4.1 does work.
comment:5 by , 9 years ago
Why does secure log in work with Web+ in Alpha 4.1 and not with the latest "improved" revision of the browser? Apparently another regression.
follow-up: 9 comment:7 by , 9 years ago
Probably a cookie expiration date computation problem.
The whole network backend for the web browser was replaced, so yes, there are regressions. On the other hand, it made a lot of other apps possible, as they use the same network code: HaikuDepot, Weather, fRiSS, and probably there will be more of these in the future.
Does this really deserve beta blocker status, knowing that you can use other browsers to access the website anyway?
comment:8 by , 9 years ago
Yes. If the default web browser is too unstable, then we should make some other web browser the default, at least for the beta.
comment:9 by , 9 years ago
Replying to pulkomandy:
Probably a cookie expiration date computation problem.
The whole network backend for the web browser was replaced, so yes, there are regressions. On the other hand, it made a lot of other apps possible, as they use the same network code: HaikuDepot, Weather, fRiSS, and probably there will be more of these in the future.
Does this really deserve beta blocker status, knowing that you can use other browsers to access the website anyway?
Whether it's a beta blocker or not is not my call to make. However, I'll offer my opinion. Nowadays people expect to be able to do their shopping and banking on-line. The solution is to fix the problem, not tell Haiku users to use another browser, or another operating system for that matter. Currently, I cannot even read the morning news on either of the local newspaper sites with Web+ because composite blobs are not supported either. My hope is that these issues get fixed, so that all the hard work (and money) put into Web+ Eventually results in a browser that everybody can use and is as good as any other out there.
comment:10 by , 9 years ago
Well, my plan is certainly not to try to hide the issues under the carpet or something. But at the moment I can only spend a limited amount of time on Haiku and I would like to get a release out. So I'm trying to focus my time on problems that are really blocking, and trying to not continue adding tickets to the beta1 milestone (otherwise, the beta1 will never be released).
I sent my plan for a release to the development mailing list some time ago: the idea is to have beta1 then update it through packages, and possibly have other beta releases much more frequently until we reach R1. This could make it possible to fix the issues as we go; however, the beta1 will probably get a lot of exposure and we may want to polish it a bit more. But then, it would not really be a beta anymore, and it would be a final release.
As for the remaining bugs in Web+ and the network backend, I would appreciate a lot if other people would have a look at the code. The "blob" issue is probably rather easy to fix, and it would be a good way for someone to get started with webkit development. A single dev working spare-time on it is not going to give results fast.
comment:11 by , 9 years ago
I'm happy to hear you're not going to dump Web+ for a port. It would be a shame after all the effort you and Ryan put into it to get it where it is today. I probably use Alpha 4.1 more than the nightlies, and so it is easy to see where progress was made, and where the regressions are.
by , 9 years ago
Attachment: | screenshot1.png added |
---|
comment:12 by , 9 years ago
Hello, as «screenshot1.png» shows, I can't log in my gmail account. The «about» window shows this info:
HaikuWebKit 1.4.12 WebKit 601.1.30
To reproduce the failure just enter the gmail-service website and go to login.
I think my problem is very similar to that of vidrep, because of that I don't think a new ticket needs to be posted. Otherwise warn me and delete my content and I'll publish it on a new ticket.
comment:13 by , 9 years ago
Unfortunately I can't test this myself (my bank does work just fine...). We would need a website where this happens and I can easily create an account. I guess no one will want to share its login credentials for a banking website with me so I can test (and that's not something I want to do).
comment:14 by , 9 years ago
You could try to open a TD Every Day Chequing Account: http://www.tdcanadatrust.com/products-services/banking/accounts/savings-accounts/index-saving.jsp
Is there any kind of log or test that can be used at my end to find the source of the problem? Like I said earlier, Alpha 4.1 works OK. So, what changed in the newer builds that would cause this issue?
comment:15 by , 9 years ago
Like I said earlier (https://dev.haiku-os.org/ticket/11236#comment:7), alpha 4.1 was using cURL, and we are now using our own code for HTTP. This means the code is completely different.
You could enable cookie tracing (uncomment TRACE_COOKIE in src/kits/network/libnetapi/NetworkCookieJar.cpp) and recompile the lib in debug mode ({{{SetConfigVar DEBUG : HAIKU_TOP src kits network libnetapi : 1 : global ; }}} in UserBuildConfig). Then run WebKit from terminal and capture the output. Maybe we can see what's wrong, but usually it is quite hard to find the exact issue.
During the next days I plan to add a cookie manager window to Web+, maybe it will help if we can compare cookies with another web browser.
comment:16 by , 9 years ago
I'll follow your instructions to enable cookie tracing tonight after work, and report back with any results. I've been getting a lot of practice lately doing these debug builds.
comment:17 by , 9 years ago
Logged into TD Bank this morning and navigated the website without issue. You can close the ticket. Thank you!
The page works correctly with an earlier version of Web+ 1.4.0.