AmigaKit down?

[wurzel]

Yes, it appears to be working, although the usual "splash" page with the flags isn't there.

This is on IBrowse

[motorollin]

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.

[motorollin]

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.

[sim085]

Mine is working now (cleared cache) although session Id is still passed from the URL.

[amigakit]

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.

[ZeBeeDee]

I'm getting no pictures of any products on any Amigakit site in IE6 and Firefox 3 @ the time of posting.



Did somebody forget to pay the photographer now? lol

[Lando]

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  :-?

[Phantom]

It seems to work, but any images don't want to load. This is with iBrowse 2.4.

[ZeBeeDee]

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 :-)

[klx300r]

working great for me with firefox 2.01

[Piru]

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

[LoadWB]

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:

[motorollin]

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 :-?

[LoadWB]

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.

[motorollin]

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?

[amigakit]

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.