Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: tonyyeb on August 13, 2008, 03:42:13 PM
-
Hi all
Anyone else finding AmigaKit's web site is down?
-
Yes.
-
Yes, maybe they are upgrading it or something like that :)
-
Sorry about this- we are experiencing high levels of traffic on the US server- the UK server is still running though: http://www.amigakit.co.uk
-
Back up and running now :-)
-
Bananas for you Amigakit:
:banana: :banana: :banana: :banana: :banana:
-
I still can't access any of the servers. I'm getting an "URI Too Large" error. Oh well. Guess I'll just have to wait.
-
Caius wrote:
I still can't access any of the servers. I'm getting an "URI Too Large" error. Oh well. Guess I'll just have to wait.
Getting the same error for the UK site.
-
Can you pmail me the exact URL that is in your web browser bar when you get this error and also tell me what browser you are using. Thanks.
-
uk.amigakit.com and amigakit.co.uk both working fine here on Safari and Firefox.
-
I've got it working now on the UK server. Just for the record, though. I've been getting that same error message often in the past too. But then it has been enough to refresh the browser to continue. Using FireFox3.
-
Hmmm, mystery. If someone gets the URI Too large error, please pmail me the full link from your browser so we can get to the bottom of this problem ASAP.
-
Maybe the session ID (which seems to be passed within the URL) happens to sometimes go above the limit on the number of characters the web server will accept as a valid URL.
-
I had the url is too long error when I was using FireFox the other day. I then used IE and the site entered normally. I therefore think this is a website issue when FireFox is used.
-
IE7 works fine but firefox 3.0.1 gets URL too long:
http://amigakit.leamancomputing.com/catalog/GBP.php?lcsid=xxxxxxxxxxxxxxxxxxxxxxxxxxx
-
Looks like whatever redirects to GBP.php is appending the session ID loads of times instead of just once. If you edit the URL to just http://amigakit.leamancomputing.com/catalog/GBP.php?lcsid=xxxxxxxxxxxxxxxxxxxxxxxxxxx then does it work?
Edit - edit your post to remove the session ID. I just got in to your account!
Edit - it's ok, I just did you a favour and logged you off so the session ID is no longer valid.
-
OK thanks for the feedback- in interests of security, please edit the session IDs out of this thread ASAP! Thanks.
-
amigakit wrote:
in interests of security, please edit the session IDs out of this thread ASAP! Thanks.
Ok, done. Though it shouldn't matter now since I logged the session out.
-
I've been getting the too long message for over 2 weeks!
Still can't get on. :-(
I'm using Safari.
-
Do you have Cookies enabled?
What page are you viewing to generate that huge URL? Do you press reload a few times?
-
The error happens when selecting the store. Selecting any store on FireFox it will generate that error?
-
Wow...the message above with the LONG URL seems to have impacted the message base here. I've got the message windows pushed very wide here!
I've forwarded the URL I received via email. I can access the front door but when I select store I end up with the 414 error!
Bob
-
beller wrote:
Wow...the message above with the LONG URL seems to have impacted the message base here. I've got the message windows pushed very wide here!
I've forwarded the URL I received via email. I can access the front door but when I select store I end up with the 414 error!
Bob
Sorry that was my post with what turned out to be a HHHUUUUGGGGEEE URL!
@Amigakit
Why is the session URL sensitive? I've seen people post links with the session ID in, are people putting personal data at risk?
-
@AmigaKit
Still getting the 404:
(http://img29.picoodle.com/img/img29/3/8/13/f_amigakitdowm_050b74a.jpg)
:-(
-
amigakit wrote:
OK thanks for the feedback- in interests of security, please edit the session IDs out of this thread ASAP! Thanks.
I'd say perhaps that in the further interest of security that those session ID things be not used. If that's impossible, maybe do like how there is a generic URL that loads things from a session ID accessible page.
-
Working in IE7 again but not Firefox 3.0.1 (long url issue).
Tried deleting cookies but still no joy.
-
Tested with Firefox 3 with no issues here. Pmail me with the offending link.
-
amigakit wrote:
Tested with Firefox 3 with no issues here. Pmail me with the offending link.
Cleared cache again and now www.amigakit.co.uk works fine in firefox 3.0.1.
-
OK, Working now.
Dunno what the issue was. :-?
-
Yes, it appears to be working, although the usual "splash" page with the flags isn't there.
This is on IBrowse ;)
-
tonyyeb wrote:
Why is the session URL sensitive? I've seen people post links with the session ID in, are people putting personal data at risk?
The session ID is used to identify which user is logged on. When I clicked the link with your session I was able to access the site as if I were logged on as you, meaning I could access your account. That's why it is not secure to post a link with a session ID.
-
weirdami wrote:
I'd say perhaps that in the further interest of security that those session ID things be not used. If that's impossible, maybe do like how there is a generic URL that loads things from a session ID accessible page.
The session ID can be stored in a cookie and passed to the web server, or passed between pages by storing it in $_SESSION. Either of these would be preferable to passing the session ID in the URL.
-
Mine is working now (cleared cache) although session Id is still passed from the URL.
-
We have added additional checking now linked to the Session ID which will terminate the session. To catch users that forget to log out, we are implementing a script to auto-logoff if the user leaves the site without selecting logoff.
-
I'm getting no pictures of any products on any Amigakit site in IE6 and Firefox 3 @ the time of posting.
(http://i528.photobucket.com/albums/dd328/amiga-org/Clipboard02.jpg)
Did somebody forget to pay the photographer now? lol
-
ZeBeeDee wrote:
I'm getting no pictures of any products on any Amigakit site in IE6 and Firefox 3 @ the time of posting.
Same here in Safari :-?
-
It seems to work, but any images don't want to load. This is with iBrowse 2.4.
-
I'm starting to see some pictures of products in both IE6 & Firefox now.
*Addendum*
All pictures of products are showing once again for me on the UK site, other Amigakit sites are slowly coming back :-)
-
working great for me with firefox 2.01
-
Session token should be transferred either via cookie or HTTP POST, never thru HTTP GET.
With HTTP GET the session tokens leak to server logs, to other sites via HTTP-referer header, proxies, browser cache, browser url history, links posted by the user etc. This is especially grave if the session is related to financial dealings such as ordering product using some pre-existing account.
http://en.wikipedia.org/wiki/Session_hijacking
http://en.wikipedia.org/wiki/Session_fixation
-
motorollin wrote:
The session ID can be stored in a cookie and passed to the web server, or passed between pages by storing it in $_SESSION. Either of these would be preferable to passing the session ID in the URL.
The PHPSESSION value stored in a Cookie or POST identifies the session to a new page in order to populate the $_SESSION super-global. So you can't store the session ID in a $_SESSION variable and expect it to work. A cookie is preferable to POST as the POST would require a hidden variable in a form rendered in plain-text html, and therefore subject to cache snooping after the fact.
Most of the time what happens is people are so overly paranoid about cookies that they don't allow them, period. This breaks many sites' functionality. Good, active anti-malware software and having third-party cookies disabled in the browser will generally keep users' machines clean (generally.) Disabling cookies altogether is a bad thing, IMHO.
I'll accept any cookie, so long as it's chocolate chip or white chocolate chip without the nuts. :crazy:
-
LoadWB wrote:
The PHPSESSION value stored in a Cookie or POST identifies the session to a new page in order to populate the $_SESSION super-global. So you can't store the session ID in a $_SESSION variable and expect it to work.
I'll have to take your word for that. I could never get sessions working properly using $_SESSION so I don't think I understood it properly. I ended up storing the user's variables in a database table and recovering them using the session ID stored in the cookie :-?
-
motorollin wrote:
LoadWB wrote:
The PHPSESSION value stored in a Cookie or POST identifies the session to a new page in order to populate the $_SESSION super-global. So you can't store the session ID in a $_SESSION variable and expect it to work.
I'll have to take your word for that. I could never get sessions working properly using $_SESSION so I don't think I understood it properly. I ended up storing the user's variables in a database table and recovering them using the session ID stored in the cookie :-?
It's actually easier than it seems. Before you send any output to the browser, issue a start_session() then you can begin populating $_SESSION variables. On the next page, issue a start_session() again and you can use the variables. When you're done, issue a session_destroy() and that's it.
In interim pages you can also issue a session_regenerate_id() to avoid session fixations. This calculates a new session id and issues it to the browser. Put "true" as the function parameter and it will also destroy the old session store (the file, mm entry, sqlite row, etc.) while transferring the $_SESSION variables to under the new ID.
-
LoadWB wrote:
It's actually easier than it seems. Before you send any output to the browser, issue a start_session() then you can begin populating $_SESSION variables. On the next page, issue a start_session() again and you can use the variables. When you're done, issue a session_destroy() and that's it.
So how does the web server know which session to issue to the browser on subsequent calls to start_session()? Is there a predefined variable which you set to the session ID for start_session() to pass back?
-
OK - we have implemented full cookie session IDs- this will mean that to shop, you have to now enable cookies for the site if you have disabled them. Feedback is welcomed.
This should also elimiate the URI too long error that a small amount of users were getting.
-
motorollin wrote:
So how does the web server know which session to issue to the browser on subsequent calls to start_session()? Is there a predefined variable which you set to the session ID for start_session() to pass back?
Using LiveHeaders, I see that every connection to the server the browser sends a Cookie: header with the PHPSESSION value. The server can then react upon it if the session is still valid. The start_session() doesn't necessarily instantiate a session, it enables your page to use a session.
What I just noticed, and I'm not quite sure where to point the finger on this one, is that between my Firefox 3 and PHP5, an old session ID is being reused. This probably has to do with cookie expiration (default is 0, which is to expire when the browser closes, which I generally hardly ever close) and me not generating new session IDs... which I will definitely start doing.
I did find a note in PHP's bug system from 2001 which illustrated that a client can specify the session ID when instantiating a new session. In the end, it was decided that this is not a bug.