[RSS] syndicatie voor private secties op site

[Verwijderd]

Hoi!

Reeds geruime tijd maak ik gebruik van RSS en ik vind het een fantastisch iets. Nu wou ik voor mijn forum ook RSS ondersteunen. Maar dat forum is voor een groot deel private. Niet elke user heeft dus dezelfde rechten op bepaalde (sub-)forums. Wat ik wil is dus een algemene RSS waarin bijv. de laatste 30 topics staan die de user kan zien. Dus elke user heeft in principe zijn 'persoonlijke' RSS: de ene gebruiker ziet wèl topics uit forum A, terwijl de andere dat niet kan.

Hoe kan ik dit het beste aanpakken? Op dit moment kom ik niet verder dan een php-scriptje, dat gegeven een id (dat voldoende uniek is, bijv. 32 characters lang, zodat het niet gegokt kan worden door externen - of iig. alleen door brute force, waarvoor ik uiteraard ook een beveiliging moet verzinnen), bijvoorbeeld één of andere permanente session id van de gebruiker (uiteraard mag dat id nooit wijzigen, want dan moet de user telkens opnieuw een 'nieuwe RSS locatie' toevoegen aan zijn RSS-programma), zijn overeenkomstige RSS-file aanmaakt, hetgeen de recente topics bevat.

Is dit een goede aanpak en is dit voldoende veilig? Ik ben er mij van bewust dat het in principe een beetje de bedoeling van RSS (public <-> private) tegenspreekt, maar het lijkt mij wel een leuke toepassing

bedankt

[4Real]

De RSS hier wordt gemaakt door een PHP file die gebruikersrechten uit een database halen en daardoor kunnen ze zien welk forum een user mag zien


Je moet dus users in groepen gooien en die rechten geven (users apart rechten geven kan ook maar in groepen in makkelijker besturen zeg maar)

[ Voor 34% gewijzigd door 4Real op 28-06-2004 20:06 ]

[Johnny]

Het zal misschien wel werken zo, maar het lijkt mij makkelijker om dan gewoon ATOM te gaan gebruiken, dat ondersteunt namelijk als standaard authentication

[Verwijderd]

4Real schreef op 28 juni 2004 @ 20:05:
De RSS hier wordt gemaakt door een PHP file die gebruikersrechten uit een database halen en daardoor kunnen ze zien welk forum een user mag zien


Je moet dus users in groepen gooien en die rechten geven (users apart rechten geven kan ook maar in groepen in makkelijker besturen zeg maar)

Oké, hetzelfde zoals ik al dacht dus. Mijn rechten en dergelijke (usergroups, ...) zijn reeds gemaakt, en werken perfect; daar gaat de vraag ook niet rechtstreeks over.

Het komt dus eigenlijk op het volgende neer: ipv. een 'makkelijk te raden' user id toe te kennen aan mijn users (bijv. 1, daarna 2, vervolgens 3, ...) moet ik dit veranderen naar een 'moeilijk te raden' user id (zoals reactID: 32 cijfertjes lang).

edit: misschien kan ik beter 2 user ids toekennen: het 'makkelijk te raden' user id, dat ik gewoon verder blijf gebruiken in mijne database en het 'moeilijk te raden' user id, hetgeen ik alleen voor zaken als RSS ga gebruiken. Reden: strings vergelijken is wat kostelijker dan integers vergelijken, en een goed database-model is eigenlijk constant aan het joinen (dus de user ids worden vergeleken).

Johnny schreef op 28 juni 2004 @ 20:11:
Het zal misschien wel werken zo, maar het lijkt mij makkelijker om dan gewoon ATOM te gaan gebruiken, dat ondersteunt namelijk als standaard authentication

Hier zal ik eens naar kijken (heb vandaag niet veel tijd, maar ik doe het zeker in de komende dagen). Alleen kan ik misschien dit al vragen: is dit te gebruiken i.c.m. RSS, want ik heb niet de zin & tijd om nog een eigen, externe applicatie te schrijven, die 'mijn eigen formaat' verstaat. Of zie ik dat verkeerd?

[ Voor 45% gewijzigd door Verwijderd op 28-06-2004 20:15 ]

[Verwijderd]

Trebel schreef op 28 juni 2004 @ 20:14:
[overbodig geworden door edit hierboven]

Ik had het nog gelezen, thanks, tot hiertoe te beste oplossing denk ik

mod: dit kan ook wel weg dan, thanks

[ Voor 9% gewijzigd door Verwijderd op 28-06-2004 20:18 ]

[.oisyn]

Zowel hier met React als op mijn eigen forum kun je gewoon een session id meegeven, dat lijkt me wel het handigst. Desnoods maak je een sessie generator scriptje waarmee je simpelweg je user/pass combo kunt opgeven en dat je vervolgens een nieuwe sessie id terug krijgt. En waarom zou een session id ineens kunnen veranderen?

En trouwens, een brute force protection is ook een beetje overdreven. Als je sessie id een MD5 ergens van is, dan zijn er 2¹²⁸ mogelijkheden, dat is meer dan een 3 met 38 nullen. Al zou je een miljoen mogelijkheden per seconde kunnen testen, dan nog ben je 3e32 seconden = 1e25 jaar bezig. Al zou je een miljoen sessies hebben die homogeen zijn verdeeld over die 2¹²⁸ mogelijkheden, dan nog is iemand 1e19 jaar bezig om met 100% zekerheid een geldige sessie id te vinden

[Verwijderd]

.oisyn schreef op 28 juni 2004 @ 20:21:
Zowel hier met React als op mijn eigen forum kun je gewoon een session id meegeven, dat lijkt me wel het handigst. Desnoods maak je een sessie generator scriptje waarmee je simpelweg je user/pass combo kunt opgeven en dat je vervolgens een nieuwe sessie id terug krijgt.

Oké dat is duidelijk. Gewoon een 2e id/hashwaarde/... naast de gebruikelijke user id dus!

En waarom zou een session id ineens kunnen veranderen?

Dat komt waarschijnlijk omdat jij een andere definitie van session id's hebt dan ik Ik zie de term 'session id' als een string/getal dat de huidige (browser) visit uniek beschrijft. Dus telkens als de gebruiker de browser uit en vervolgens aan zet, krijgt hij een nieuw session id. Zo sla ik tijdelijke sessie-variabelen op in de database en ik link die met de gebruiker dmv. zijn huidig session id. (bijvoorbeeld voor http://be.php.net/manual/...sion-set-save-handler.php). Zo kan de gebruiker dus ook 10 browsers open hebben, met elk een verschillende session id.

Een kwestie van definitie dus denk ik

En trouwens, een brute force protection is ook een beetje overdreven. Als je sessie id een MD5 ergens van is, dan zijn er 2¹²⁸ mogelijkheden, dat is meer dan een 3 met 38 nullen. Al zou je een miljoen mogelijkheden per seconde kunnen testen, dan nog ben je 3e32 seconden = 1e25 jaar bezig. Al zou je een miljoen sessies hebben die homogeen zijn verdeeld over die 2¹²⁸ mogelijkheden, dan nog is iemand 1e19 jaar bezig om met 100% zekerheid een geldige sessie id te vinden

Akkoord, maar je moet niet alle gevallen beschouwen om een geldig id te pakken te krijgen; alleen in worst-case hoeft dit (en er zijn maar 2 gebruikers: jezelf en de andere = laatste stap van de 2^128 stappen). Wie weet heb je na 1000 iteraties al de session id van de headadmin te pakken

[ Voor 4% gewijzigd door Verwijderd op 28-06-2004 20:29 ]

[.oisyn]

Verwijderd schreef op 28 juni 2004 @ 20:27:
Dat komt waarschijnlijk omdat jij een andere definitie van session id's hebt dan ik Ik zie de term 'session id' als een string/getal dat de huidige (browser) visit uniek beschrijft. Dus telkens als de gebruiker de browser uit en vervolgens aan zet, krijgt hij een nieuw session id. Zo sla ik tijdelijke sessie-variabelen op in de database en ik link die met de gebruiker dmv. zijn huidig session id. (bijvoorbeeld voor http://be.php.net/manual/...sion-set-save-handler.php). Zo kan de gebruiker dus ook 10 browsers open hebben, met elk een verschillende session id.

Een kwestie van definitie dus denk ik

Dat is idd de officiele definitie van sessie, maar hoe zorg je er dan voor dat gebruikers ingelogd blijven, zelfs nadat de browser is afgesloten?

Akkoord, maar je moet niet alle gevallen beschouwen om een geldig id te pakken te krijgen; alleen in worst-case hoeft dit (en er zijn maar 2 gebruikers: jezelf en de andere = laatste stap van de 2^128 stappen). Wie weet heb je na 1000 iteraties al de session id van de headadmin te pakken

Uiteraard, maar uit een beetje denkwerk volgt dat de kans een sessie te pakken bij 1 miljoen verschillende sessies gelijk is aan 1000 / (2¹²⁸ / 1.000.000) = 1 / 3.402e35. Dat is ongeveer hetzelfde als 45 achter elkaar met een dobbelsteen 6 gooien. Probeer dat eens? Met andere woorden: verwaarloosbaar.

[Verwijderd]

.oisyn schreef op 28 juni 2004 @ 20:56:Dat is idd de officiele definitie van sessie, maar hoe zorg je er dan voor dat gebruikers ingelogd blijven, zelfs nadat de browser is afgesloten?

Ik snap je vraag niet helemaal, maar ik hou in een cookie zijn session id bij. Indien een gebruik inlogt kijk ik of er een overeenkomstige session id bestaat voor die user in de database. Zo kan een user dus meerdere 'persistent sessions' maken: eentje voor op het werk, eentje thuis, ... Als hij nu uitlogt op 1 sessie (dus de overeenkomstige sessie in de database wordt gewist), hoeft dat nog altijd niet te betekenen dat hij thuis opnieuw hoeft in te loggen.

Uiteraard, maar uit een beetje denkwerk volgt dat de kans een sessie te pakken bij 1 miljoen verschillende sessies gelijk is aan 1000 / (2¹²⁸ / 1.000.000) = 1 / 3.402e35. Dat is ongeveer hetzelfde als 45 achter elkaar met een dobbelsteen 6 gooien. Probeer dat eens? Met andere woorden: verwaarloosbaar.

Verwaarloosbaar is relatief, maar ik ga akkoord: het is een beetje te overdreven

[.oisyn]

Verwijderd schreef op 28 juni 2004 @ 21:07:
[...]
Ik snap je vraag niet helemaal, maar ik hou in een cookie zijn session id bij. Indien een gebruik inlogt kijk ik of er een overeenkomstige session id bestaat voor die user in de database. Zo kan een user dus meerdere 'persistent sessions' maken: eentje voor op het werk, eentje thuis, ... Als hij nu uitlogt op 1 sessie (dus de overeenkomstige sessie in de database wordt gewist), hoeft dat nog altijd niet te betekenen dat hij thuis opnieuw hoeft in te loggen.

Ah, je wekte de indruk dat een sessie werd afgesloten zodra je een browser eindigde. Dit is wat jij zei:

Ik zie de term 'session id' als een string/getal dat de huidige (browser) visit uniek beschrijft. Dus telkens als de gebruiker de browser uit en vervolgens aan zet, krijgt hij een nieuw session id

Maar dat is dus blijkbaar niet zo. In dat geval hebben we hetzelfde idee over sessies

[Verwijderd]

.oisyn schreef op 28 juni 2004 @ 21:16:
[...]


Ah, je wekte de indruk dat een sessie werd afgesloten zodra je een browser eindigde. Dit is wat jij zei:

[...]


Maar dat is dus blijkbaar niet zo. In dat geval hebben we hetzelfde idee over sessies

Oops, verkeerd uitgedrukt dan De sessie wordt alleen verbroken indien de user daar zelf omvraagt: hij wil uit eigen wil uitloggen. Dus bij het uitzetten van de browser blijft de sessie geldig (dus ook het id), en gaat de user bij de volgende visit verder met zijne vorige session (dus ook het id). Hij kiest de juiste session (hij kan er meerdere hebben!) dmv. de waarde in zijn cookie.

Ik snap je opmerking "En waarom zou een session id ineens kunnen veranderen?" dan niet helemaal: session id kan toch perfect veranderen: de user logt uit -> session gewist -> logt opnieuw in -> nieuwe session; dus ook nieuw id.Of zie ik dat verkeerd?
En dus ook de RSS-URL koppelen aan zijn session id, is ook geen goed idee volgens mij:
1) telkens hij een nieuwe session id krijgt, moet de url aangepast worden (er staat iets als '?sessionid=...' in de RSS-URL).
2) een user kan meerdere sessies hebben (thuis, werk, ...)

bedankt

[ Voor 12% gewijzigd door Verwijderd op 28-06-2004 21:34 ]

[.oisyn]

Hij moet ook niet die sessie uitloggen die ie gebruikt voor z'n rss feed he

[Verwijderd]

Oké, fair enough

Persoonlijk maak ik dan liever een 'tweede user id/hash' aan, dan een extra 'RSS session', omdat ik vind dat RSS & sessions niet rechtstreeks iets met elkaar te maken hebben, en omdat ik per session gegevens bijhoud (session vars) in de database, die voor RSS helemaal niet nodig zijn: alleen nuttig voor het surfen.

[ Voor 4% gewijzigd door Verwijderd op 28-06-2004 21:39 ]