Keskustelu: Nettisivujen teko: PHP, .htaccess, sessio/cookie ja dynaamiset osoitteet

Käytössä on .htaccess-tiedosto, jolla ohjataan nettisivuliikennettä. Jostain syystä PHP:llä sessio/cookie ei pysy "elossa" määritettyä ajanjaksoa, jos käytetään dynaamisia osoitteita eikä ko. osoitetta ole todellisuudessa olemassa. Jos haettu osoite ei ole dynaaminen vaan se on oikeasti palvelimella oleva .php-päätteinen tiedosto, sessio/cookie pysyy "elossa" halutun ajan.

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{HTTP_HOST} ^oma.minundomain.ltd
RewriteCond %{QUERY_STRING} ^$
RewriteRule ^hakemisto/([0-9]+)$ /hallinta_hakemisto/?id=$1 [L]

Sessio/cookie luodaan kaikissa alidomaineissakin toimivaksi seuraavasti:

$elinaika_sekunneissa = 23 * 3600; # 23 tuntia
session_set_cookie_params($elinaika_sekunneissa, '/', '.minundomain.ltd');
session_name("OmaSessio");

session_start();

Sessio/cookie-koodin sisältävä PHP-skripti ajetaan jQueryllä 30 sekunnin välein eli voimassaoloaika päivittyy kaiken aikaa, mutta jostain syystä sessio/cookie ei silti pysy elossa 23 tuntia, jos osoitteet ovat dynaamisia.

Osaisiko joku sanoa, miksei toimi dynaamisilla osoitteilla vaan sessio/cookie erääntyy liian aikaisin?

PS. Vielä lisäyksenä, että dynaamisella sivulla Chromella näkyy cookie oikein (minundomain.ltd -> Evästeet -> OmaSessio), mutta kohtaa oma.minundomain.ltd -> "Käyttökerran tallennustila" ei näy. Mutta jos osoite ei ole dynaaminen, myös tuo "Käyttökerran tallennustila" näkyy Chromessa OK.

Oletko kokeillut tarkastella HTTP-kyselyitä selaimen kehittäjätyökaluilla?

Jos vertailet niitä kyselyitä, joissa URI on 'dynaaminen' niihin joissa se osoittaa olemassa olevaan .php-tiedostoon, näetkö eroja evästeissä jotka selain lähettää kyselyn mukana?

Ja jos teet saman vertailun palvelimelta tuleville vastauksille, näetkö eroja evästeissä, jotka palvelin lähettää vastauksen mukana?

En tiedä, olenko oikeasta paikasta Chromea noita kaikkia tutkinut, mutta tuo avauspostauksen PS.-kohdassa mainitsemani on ainoa ero, jonka olen havainnut URI:n ollessa dynaaminen.

Et varmaankaan pysty laittamaan linjoille mihinkään osoitteeseen? Olisi luultavasti helpompi katsoa itse eri vaihtoehdot läpi kuin alkaa listaamaan asioita mitä voi katsoa.

Ja siis nimenomaan kiinnostaisi tuo "dynaaminen" malli, jossa ne ei toimi.

xxmss kirjoitti:

En tiedä, olenko oikeasta paikasta Chromea noita kaikkia tutkinut, mutta tuo avauspostauksen PS.-kohdassa mainitsemani on ainoa ero, jonka olen havainnut URI:n ollessa dynaaminen.

Tarkoitin siis kehittäjän työkaluja, jotka saa auki painamalla Ctrl + vaihto + j tai F12.

Ottaen huomioon että tuo PS-kohdassa mainittu asia on juuri siellä kehittäjän työkaluissa, niin eiköhän xxmss niillä huudeilla ole ollut.

Siis sinänsähän tuo, että "Session Storage" / "Käyttökerran tallennustila" ei näy, viittaa nimenomaan siihen, että selain ei ole tallentanut ko. sivustolta yhtään evästettä. Sen syyn selvittämiseen vesikuusi antoi sinänsä ihan hyvät neuvot, mutta jos ne ei auta niin vaikea sanoa pitäisikö antaa paremmat ohjeet vai onko ongelma noudattamisessa. Siksi sanoin että jos pääsisi itse katsomaan todellista tilannetta, voisi olla helppokin selvittää.

Niitä vastauksia ja pyyntöjä pääsee katsomaan välilehdeltä network tai ehkä verkko suomeksi. Välilehti pitää yleensä avata ensin ja sitten vasta tehdä pyynnöt, jotta ne näkyisivät. Hyvä hakusana tähän asiaan on esimerkiksi: How to see request and response in Chrome?

Tutkin vähän tarkemmin tuolta Chromen Network-välilehden kautta. Huomasin eron cookieissa. Jos ei ole kyseessä dynaaminen osoite, näkyy cookie vain kohdassa "Response Cookies" ja sivu uudelleen ladattaessa kohdassa "Request Cookies", mutta tilanteesta riippuen vain jommassa kummassa. Jos osoite on dynaaminen, cookie näkyy sekä kohdassa "Request Cookies" että "Response Cookies". Erona se, että "Response Cookies" -kohdassa cookien sisältö on eri ja cookien Expires-arvona lukee "23.0 hrs" eikä tarkkaa erääntymisaikaleimaa, kuten "Request Cookies" -kohdassa näkyvässä cookiessa.

Tutkin vielä tarkemmin ja ilmeni, että ongelma liittyy vain alidomainiin. Jos dynaamista kuvitteellista tiedostoa ei alidomainin alaisuudessa ole olemassa, ongelma ilmenee. Muussa tapauksessa toimii OK, vaikka haettu sivu olisikin alidomainin alla.

xxmss kirjoitti:

Tutkin vielä tarkemmin ja ilmeni, että ongelma liittyy vain alidomainiin. Jos dynaamista kuvitteellista tiedostoa ei alidomainin alaisuudessa ole olemassa, ongelma ilmenee. Muussa tapauksessa toimii OK, vaikka haettu sivu olisikin alidomainin alla.

Mikä ihme on "dynaaminen tiedosto"? Mikä hitto on "dynaaminen osoite"? Ei ole mitään dynaamisia osoitteita. Joko urli on kelvollinen, eli palvelin tunnistaa sen ja osaa käsitellä pyynnön, tai sitten se on epäkelpo, eli palvelin ei tunnista sitä ja yleensä antaa virhekoodin 404.

xxmss kirjoitti:

Tutkin vähän tarkemmin tuolta Chromen Network-välilehden kautta. Huomasin eron cookieissa. Jos ei ole kyseessä dynaaminen osoite, näkyy cookie vain kohdassa "Response Cookies" ja sivu uudelleen ladattaessa kohdassa "Request Cookies", mutta tilanteesta riippuen vain jommassa kummassa.

No katsos kun yleensä nettisivut toimivat niin, että evästeitä asetetaan vain POST-pyynnöissä, jos kyse on sisäänkirjautumisesta tai vaikka ostoskorin tyyppisestä kevyttä tunnistautumista vaativasta tilanteesta.

Sen sijaan eväste kyllä lähtee matkaan (selaimesta palvelimelle) tasan jokaisessa HTTP-pyynnössä (GET ja POST ja kaikki muutkin metodit), jos sellainen on olemassa. Jos eväste ei vaikuta lähtevän tasan jokaisella pyynnölllä, niin joko et osaa lukea devtoolsin tietoja tai sitten olet poistanut evästeen.

muuskanuikku kirjoitti:

Jos eväste ei vaikuta lähtevän tasan jokaisella pyynnölllä, niin joko et osaa lukea devtoolsin tietoja tai sitten olet poistanut evästeen.

Siis xxmss:n kertoman mukaan näyttää aivan selvältä että palvelimen lähettämä eväste ei "tallennu" selaimelle ensinkään. Tai tallentuu eri osoitteeseen tms. Lähinnä siis pitäisi selvittää mistä se johtuu.

Grez kirjoitti:

(24.07.2024 08:26:19): ”– –” Siis xxmss:n kertoman mukaan näyttää aivan...

Hänen kertomansa mukaan selain kuitenkin vastaanottaa evästeen. Sitten tarvitsee vain katsoa evästeen arvoja ja miettiä, että onko niissä jokin virhe, jos se katoaa jonnekin.

Niin, kenties evästeelle on vaikkapa määritelty Secure-lippu mutta yhteys on http, tai selain jostain vastaavasta syystä hylkää evästeen eikä tallenna sitä. Kuitenkin normaalisti jos selain vastaanottamisen jälkeen "hyväksyy" ja tallentaa evästeen, niin se tulee tuonne devtoolsin "Käyttökerran tallennustila" kohtaan näkyviin - ja nyt se ei xxmss:n havaintojen mukaan tule silloin kun "dynaaminen" systeemi (mitä sitten tarkoittaakin) on käytössä.

Tässä vielä ChatGPT:n näkemys syistä, joiden takia selain voi hylätä evästeen. Ehkä xxmss:n kannattaa käydä nämä läpi:

ChatGPT kirjoitti:

Selain saattaa jättää palvelimelta tulevan evästeen tallentamatta useista syistä, jotka voivat liittyä evästeen asetuksiin, selaimen asetuksiin tai käyttäjän toimenpiteisiin. Tässä on yleisimpiä syitä:

Turvallisuusasetukset (Secure flag):

1. Eväste on määritelty vain HTTPS-yhteyksille (Secure-lippu), mutta sivusto käyttää HTTPä.

2. HTTPOnly-asetus:

• Eväste on asetettu HttpOnly, mikä tarkoittaa, että sitä ei voi lukea tai kirjoittaa JavaScriptin kautta. Tämä ei estä evästeen tallentamista, mutta rajoittaa sen käytettävyyttä.

3. SameSite-politiikka:

• SameSite-attribuutti määrittää, että evästeitä ei lähetetä ristiin sivustojen välillä. Jos eväste on asetettu SameSite=Strict, se lähetetään vain saman sivuston sisällä, mikä voi estää sen tallentamisen joissain tapauksissa.

4. Domain ja Path attribuutit:

• Evästeen domain- ja path-asetukset eivät täsmää nykyisen URL kanssa.

5. Evästeen koko:

• Eväste on liian suuri. Selaimet rajoittavat yksittäisen evästeen koon yleensä noin 4 kilotavuun.

6. Palvelimen aika-asetukset (Expires/Max-Age):

• Evästeen vanhentumisaika (Expires tai Max-Age) on määritelty väärin, esimerkiksi menneisyyteen, mikä johtaa evästeen välittömään poistamiseen.

7. Selaimen asetukset ja käyttäjän toimenpiteet:

• Käyttäjä on estänyt evästeiden tallentamisen selaimen asetuksista.
• Selain käyttää yksityistä selaustilaa (incognito mode), jossa evästeiden tallennus on rajoitettu tai estetty.
• Käyttäjä on asentanut laajennuksia tai lisäosia, jotka estävät evästeiden tallentamisen.

8. Kolmannen osapuolen evästeet:

• Selain estää kolmannen osapuolen evästeet, jotka tulevat eri domainista kuin sivusto, jolla käyttäjä on.

9. Evästeen nimi tai arvo:

• Evästeen nimessä tai arvossa on kiellettyjä merkkejä, mikä estää evästeen tallentamisen.

10 .Same-origin policy:

• Selain saattaa estää evästeen tallentamisen, jos se ei noudata same-origin policy -sääntöjä, jotka suojaavat eri alkuperäisten resurssien sekoittumiselta.

Nämä ovat yleisimpiä syitä, miksi selain saattaa jättää evästeen tallentamatta.

Jokainen tapaus voi vaatia yksityiskohtaista tarkastelua ja diagnosointia ongelman selvittämiseksi.

Katso network-lehdeltä ihan puhtaalta pöydältä alkaen siihen asti, että vika ilmenee. Kun käyt läpi kaikki pyynnöt, voit seurata, miten evästeet muuttuvat.