Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[unkle]

Hi all!

When trying to login to amuleweb from another PC on my LAN it works only with chicane and default not php-default. But the worst thing is that when i use default or chicane i get redirected to the login-screen whenever i click a link inside the main screen (Preferences, Statistics, Transfer and so on).

Another thing that really bugs me (and makes it harder to figure out) is the fact that it works beautifully when i use the browser locally on the PC hosting amuled and amuleweb (!!).
The address i use is the same and also the browser is Firefox on both PC's.
(I also tried with IE on the remote PC with exactly the same problem).

Problems:
1: php-default keeps taking me back to login no matter what on remote pc
2: only "chicane" and "default" lets me pass the login, but then exits to login again on any action.

Im using:
aMuled 2.1.0 using wxGTK2 v2.6.2 (Unicoded) (OS: Linux)
amuleweb 2.1.0
This runs on a KnoppMyth distro.

I copied all recursively from /usr/share/amule/webserver/ to /home/mythtv/.aMule/
Im running amuled and amuleweb separately.

My apologies for this long post ! I hope its okay )

My remote.conf:

Code: [Select]

Locale=
[EC]
AcceptExternalConnections=1
ECUseTCPPort=1
ECPassword="long-md5-sum"
Host=localhost
Port=4712
Password="long-md5-sum"
[Webserver]
Port=4711
Template=chicane
UseGzip=1
AllowGuest=0
AdminPassword="long-md5-sum"
GuestPassword="long-md5-sum"
My amule.conf (edited to keep the post a little shorter, please let me know if you need all info):

Code: [Select]

"SNIP"
[ExternalConnect]
UseSrcSeeds=0
ShowPercent=0
ShowProgressBar=1
AcceptExternalConnections=1
ECUseTCPPort=1
ECAddress=localhost
ECPort=4712
ECPassword="long-md5-sum"
IpFilterOn=1
UseSecIdent=1
"SNIP"
[WebServer]
Enabled=0
Port=4711
PageRefreshTime=120
UseGzip=1
UseLowRightsUser=0
Password="long-md5-sum"
PasswordLow="long-md5-sum"
Template=chicane
"SNIP"
Output from amuleweb using chicane:

Code: [Select]

aMuleweb$
WSThread: Thread started
WSThread: created socket listening on :4711
WCThread: Started a new WCThread
Processing request [original]:
No session opened - will request login
Session created - requesting login
Session is not logged and request have no password
Processing request [redirected]: login.html
WCThread: exited [WebSocket closed]
WCThread: Started a new WCThread
Processing request [original]:
No session opened - will request login
Session created - requesting login
Checking password
Password ok
Processing request [redirected]: index.php
WCThread: exited [WebSocket closed]
WCThread: Started a new WCThread
Processing request [original]: preferences.php
No session opened - will request login
Session created - requesting login
Session is not logged and request have no password
Processing request [redirected]: login.html
WCThread: exited [WebSocket closed]
This is the output from amuled on startup:

Code: [Select]

mythtv@mythtv:~$ amuled
amuled: OnInit - starting timer
Initialising aMule
Checking if there is an instance already running...
No other instances are running.
Loading temp files from /home/mythtv/.aMule/Temp.

All PartFiles Loaded.
ListenSocket: Ok.

*** TCP socket (ECServer) listening on 0.0.0.0:4712
*** Server UDP socket (TCP+3) at 0.0.0.0:4665
*** TCP socket (TCP) listening on 0.0.0.0:4662
*** Client UDP socket (extended eMule) at 0.0.0.0:4672
Empty dir /home/mythtv/.aMule/Incoming shared
Being a newbie i hesitate using cvs-snapshots because i basically am all new to configuring and compiling stuff from scratch.

Please let me know if you need more info.
Thank you all in advance for your attention )

Regards,
unkle

[Kry]

clear your cache (cookies etc) on the browser

[lfroen]

Disable browser "acceleration" extensions.

[unkle]

Okay, ill try to clear the cache ASAP (i am at work at the moment). It just worries me that both IE and FF show the exactly the same behaviour. That would indicate to me that it doesnt have anything to do with browser acceleration settings in FF. Also the fact that it works locally on the box with FF is "corrupting" my search for the problem. But of course ill give it a go )
Thankyou!

[darksidex]

I had the same problem, and I solved it executing amuleweb with -A flag:
$amuleweb -A password

I can login now without any problem

[unkle]

Thankyou for all the replies !

I cleared the cache in FF but still no luck. I could not find any options for disabling "acceleration" so this i havent tried (yet).

I used darksidex' tip and started amuleweb with:
$amuleweb -A password
also i cleared the cookies from IE and then it worked in IE! (however i cannot confirm whether or not it was the -A flag that did the trick or if its because i cleared the cookies (or a combination of both)).
It still does not work in Firefox.

Opera was the next thing to test with and it also worked beautifully.

So... somewhat "succesful" but still frustrating that i cannot make FF cooperate since it is my primary/default browser.

To sum up on things (and for future reference):

Tested with "chicane" and "php-default"

Firefox Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8 ) Gecko/20051111 Firefox/1.5
(running on remote PC)
NOT OK.

Firefox 1.0.4-2 (Debian package)
(running locally on amule-host)
OK

Opera 8.51 build 7712
(running on remote PC)
OK

Internet Exploder v6.0.2900.2180.xpsp_sp2_gdr.050301-1519
(running on remote PC)
OK

This would indicate to me that there might be an issue with Firefox 1.5 (i might wanna try upgrading to 1.5 on the host-PC and see if it fails).
I dont have the expertise to make any comments on where the problem is to be found. I fear that it might be that the Firefox 1.5 is failing in this particular combination of OS, packages and setup. So its probably a very unique problem. Ill keep investigating and post my progress (if any).

My respect to the crew at the aMule Project for delivering such a fine piece of software. Its NICE! )

And a big thankyou for the attention and replies goes out to the people in this forum.

/unkle

[lfroen]

So its probably a very unique problem

I did not tested it with Firefox 1.5 (no FC4 rpms), so I can't tell how unique the problem is. I will make a check with windows version in a few days.

[stefanero]

I run firefox 1.5 here, no problems....

but I  had this login-loops aswell a while ago, but simple clearing cookies helped...

[darksidex]

I can login with firefox 1.5 (windows version) without any problems, running amuleweb with  "-A " flag.

[unkle]

I cleared the cache, - not the cookies in FF 1.5. I will try to clear the cookies too as soon as i get home.

But my guess is that a lot of users out there are running FF 1.5 with no problems at all so i still believe that its a unique problem. ...but, i just hate when i upgrade something later on and the problem disappear by "magic" intervention ...i hate magic solutions ! ;o)

[stefanero]

^^ if clreaing cookies helps its not magic

[unkle]

Clearing the cookies in FF worked ! ...so no magic here
Im still running with -A flag though

I've just started testing it so it might still do the thing where it randomly logs out, but this has yet to come...
Now on to the settings and making it connect !

Thankyou once again for very good support and fast feedback !!!
 :baby:

unkle

[stefanero]

I need to have a talk with lfroen why those cookies get fucked up after a while

[unkle]

Yes it seems they're a bit unstable. Also i've chosen the default-theme because i find the php-default a bit un-intuitive (also the log in the default theme is helpful in the "break-in" period).

I've been running the amuleweb for about 18 hours or so and it seems to be going strong (with stable login and links).

I think this thread has come to an end (a happy one) but ill post if something comes up with this issue.

[lfroen]

I have no idea what can go wrong with cookies. AFAIK amuleweb behaves with cookies according to appropriate RFC (I read it myself). There's only one point makes it different. In contrast to regular internet site, amuleweb have no idea about it's domain name, so cookie sent to browser doesn't have it either. Now, browser have to figure out by itself to what domain this cookie belongs in order to correctly send it back. Note, that this is ok with RFC since "domain" is optional field (client supposed be smart enough).