Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#1331 closed bug (Invalid)

No cookies set on Chromium browser

Reported by: gozza11 Owned by: damoxc
Priority: critical Milestone: 1.3
Component: Web UI Version: 1.3.0_dev
Keywords: cookies, login, webui, chrome, chromium, opera, arch Cc: goran.sterjov@…

Description

When trying to log into the webui running on an Arch Linux server i cant login with chromium and opera 10. login prompt immediately returns. login works fine with firefox. ultimately no cookies are present in chromium and opera after login whereas firefox has one.

fresh install of deluge 1.3.0 rc1. default config as followed on the ThinClient? wiki page. logs show nothing out of the ordinary with '-L debug'. strangely a fresh install with the same configuration on gentoo works flawlessly. seems to be arch linux only

Attachments (2)

deluge-web.log (18.2 KB) - added by gozza11 14 years ago.
deluge-web debug log
web.conf (5.0 KB) - added by gozza11 14 years ago.
deluge-web config file

Download all attachments as: .zip

Change History (9)

comment:1 Changed 14 years ago by damoxc

What version of chromium is this?

I have been using Chromium throughout development and it has been working fine for me.

comment:2 Changed 14 years ago by gozza11

version: 5.0.375.99

im guessing the same problem occurs with transdroid and the default browser on android as the same problem occurs whereas it works fine when gentoo is running it. not sure if its deluge or arch or something else weird. i've only tried accessing the webui from another computer on the network rather than localhost.

comment:3 Changed 14 years ago by gozza11

updated a few components. im using the following versions with no success.

(gentoo) chromium: 5.0.375.125

(arch linux server) python-mako: 0.3.4-2 twisted: 10.1.0-1 python3: 3.1.2-3 simplejson: 2.1.1-1 python-chardet: 2.0.1-1

same problem with latest git as of writing. what version has everyone else got? it doesnt look like a chromium problem since it happens on other browsers clients such as transdroid. im convinced its a web servering problem with my arch setup since deluge-gtk connects fine and serving it on my gentoo machine is flawless. for the life of me i cant figure this out.

comment:4 Changed 14 years ago by gozza11

i forgot to add that i also have 2.6.5-3 of python installed.

Changed 14 years ago by gozza11

deluge-web debug log

Changed 14 years ago by gozza11

deluge-web config file

comment:5 Changed 14 years ago by gozza11

attached is the deluge-web debug log and web.conf file. doesn't give much information but it does show the json requests for logging in. it looks like everything goes well but it doesn't go further than creating a session even though it gets written to web.conf. it must be sending the cookie session since firefox always receives it. my only conclusion is that something must mangling it since it works without problem on other systems.. i am at a loss as to how to continue investigating it. how do i find out if a cookie is being sent and received? i still dont know if this is even a deluge problem, maybe one of the deluge dependencies is mangling it (if that's what's happening)?

comment:6 Changed 14 years ago by gozza11

  • Resolution set to invalid
  • Status changed from new to closed

after scouring through the liveHTTP headers output in firefox it turns out that the only difference between the cookies from arch and gentoo was the expiry date. since my server was back 12 hours the cookie would always expire on my browser trying to log on since deluge-web login expires every hour. after changing the time on the server that runs deluge-web everything works without any problems.

it would have been great if a message had popped up telling me the error but i dont know if this is even possible. Right now its safe to say that if the login screen pops up immediately after the password was entered, check the server time to make sure it isnt sending a useless cookie. having said that firefox really should not have logged in..

comment:7 Changed 14 years ago by damoxc

A good idea. Could you create a ticket targeting milestone 1.4 for that.

Note: See TracTickets for help on using tickets.