[php5] token based rss feeds

[Verwijderd]

Een opdrachtgever wil voor de gebruikers van zijn systeem rss-feeds aanbieden, zodat deze gebruiker van diverse gegevens op de hoogte blijft middels een rss reader.

Ik kon via Google niet vreselijk veel informatie hierover vinden. Daarom mijn vraag: wie kan mij kort en bondig uitleggen wat dit precies is en hoe ik zo'n token genereer bijvoorbeeld.

[Creepy]

Ik heb geen idee wat je opdrachtgever bedoelt met een "token" maar RSS feeds genereren stelt niet zo heel veel voor. RSS specs zijn overigens goed te vinden (zie hier). Genereer een RSS feed (of eventueel meerdere per categorie o.i.d.) en die feeds kunnen direct in een feed reader worden gebruikt.

[sopsop]

Verwijderd schreef op maandag 06 augustus 2007 @ 10:40:
Een opdrachtgever wil voor de gebruikers van zijn systeem rss-feeds aanbieden, zodat deze gebruiker van diverse gegevens op de hoogte blijft middels een rss reader.

Ik kon via Google niet vreselijk veel informatie hierover vinden. Daarom mijn vraag: wie kan mij kort en bondig uitleggen wat dit precies is en hoe ik zo'n token genereer bijvoorbeeld.

Hoe bedoel je 'zo'n token' In de rest van je post komt geen token voor. En probeer de titel van je topic eens in Google. Ik vind genoeg resultaten waar je wat aan hebt.

[Kalentum]

Ik begrijp niet wat je wil. Maar voor zover ik het begrijp wil je een rss-feed genereren. Hoe dat moet is in ruime mate te vinden via Google (http://www.naarvoren.nl/artikel/rss/ bijvoorbeeld)

Wat je bedoeld met 'tokens' begrijp ik niet in deze context.

[Verwijderd]

Rss begrijp ik wel, dat is het probleem niet.
Wat ik dus wil is een beveiligde Rss feed: je moet echt een gebruiker van het systeem zijn om de feed te kunnen bekijken (het gaat om bedrijfsgevoelige informatie in dit geval). Maar ze moeten dus niet in hoeven loggen (dat zou weer een extra handeling zijn).

[Creepy]

Ah, je wilt dus iets beveiligen, maar zonder in te loggen? Heb je het hier met je opdrachtgever al over gehad hoe dat precies plaats moet gaan vinden? Als het alleen intern bereikbaar moet zijn gewoon ervoor zorgen dat de RSS feed alleen intern bereikbaar is. Of kijken of je op basis van IP toegang kan verlenen. Anders zijn er nog (client) SSL certificaten die kunnen worden gebruiken en google geeft vast nog wel meer aan.

Probeer nu eens te achterhalen / aan te geven wat nu precies de bedoeling is. Je bent nogal vaag namelijk. En probeer met je opdrachtgever af te stemmen wat de eventuele mogelijkheden zijn. Alleen met de termen RSS en token kom je in principe niet zo heel ver.

[mithras]

Hoewel het uiteraard een beveiligingsrisico is, kan je ook een sessie openen en die in je url als GET mee opvragen. Zo doet GoT het bijvoorbeeld ook, en kan je op die sessie de controle uitvoeren. Het risico van uitlekken is dan wel degelijk aanwezig, maar de methode is zeker een optie om mee te nemen

[quaintpaul]

Ik gebruik de RSS reader Netvibes: www.netvibes.com. Via Netvibes haal ik de feed van mijn PHPBB forum op (via extensie voor PHPBB). Netvibes herkent dat je wachtwoord nodig hebt voor de Feed en vraagt er om.. Erg handig! Miss kun je eens daar naar kijken hoe zij dat doen? Wat ik je tot nu kan vertellen is dat de feed authenticatie via URL ofzo doet (http://user:password@url)..

[Verwijderd]

bedankt voor de reacties tot dusver.
Ik zie dat in mijn startpost idd het stukje over token based authentificatie is weggevallen.
Had ik even geknipt om onder de post te plaatsen, maar dat ben ik vergeten terug te zetten.

IP-nummer restrictie is niet aan de orde: de feed moet voor iedere gebruiker van de webapplicatie overal te benaderen zijn. Ik wil dus eigenlijk dat elke rss feed uit het systeem aan een gebruiker gekoppeld kan worden, maar dat deze gebruiker niet zijn username/password elke keer hoeft in te geven.
Je zou natuurlijk een md5 kunnen maken van zijn username/password en dat in de koppeltabel van rssfeeds_per_user als token kunnen plaatsen. Of zou dit (erg) onveilig zijn?

[GlowMouse]

Verwijderd schreef op maandag 06 augustus 2007 @ 11:30:
Je zou natuurlijk een md5 kunnen maken van zijn username/password en dat in de koppeltabel van rssfeeds_per_user als token kunnen plaatsen. Of zou dit (erg) onveilig zijn?

Een md5-hash in een koppeltabel zetten is helemaal niet onveilig. Het gaat erom wat er vervolgens met die gegevens gebeurt, en dat is me nog niet duidelijk.

[Verwijderd]

Die gegevens:

Die md5 hash is dus de token die bij een rss feed hoort: de token kan automatisch aan de url van de rss-feed worden toegevoegd, zodat verifieert kan worden of de gebruiker de rss feed mag openen.

Dus: rss feed:

http://testdomein.nl/feeds/feed_1.php?token=md5hash

en als de gebruiker http://testdomein.nl/feeds/feed_1.php opvraagt krijgt hij een foutmeldig of een lege feed of iets dergelijks te zien.

[Creepy]

Ok, en dan nu het standaard riedeltje (wat overigens is terug te vinden in Programming Beleid - De Quickstart): Wat heb je zelf al geprobeerd? Wat lukte daar niet mee? Krijg je foutmeldingen? Zo ja, welke?

Wat je je wel moet beseffen is dat iedereen die feeds kan opvragen. Het enige wat je moet weten is de hash. Ik weet niet hoe gevoelig die informatie is maar als dit echt niet extern mag lekken dan zou ik zeker voor een andere oplossing gaan.

[quaintpaul]

@ Creepy: die opmerking is niet terecht, we proberen hier een goed DESIGN te maken. Zomaar proberen is niet aan de orde, we bespreken de achterliggende theorie..

@ Topic: Ik denk niet dat de MD5 hash voldoende veilig is! Iedereen met die URL (browser history??) kan dan de feed bekijken.. Van security is geen sprake dus! Beste methode is denk om om HTTP_AUTH te gebruiken, ofwel via .htaccess/.htpassword security te zetten op de feed file/directory.. Goeie RSS reader herkennen die HTTP_AUTH request en vragen de user weer om username/pasword.. Moet lukken!

[Creepy]

Een goed design? Ook goed, maar dan nog dient de topicstarter met een goed designvoorstel te komen. Alleen melden dat er een hash gebruikt moet worden is dat niet. Er is nog steeds erg weinig informatie gegeven. Het is hier nog steeds niet de bedoeling dat wij dat volledig gaan uitdenken voor iemand.

offtopic:
Overigens: als je meer commentaar of vragen het het beleid hebt: Feedback op moderatie binnen de Devschuur en niet hier in dit topic..
Overigens hoort een topic over design e.d. in Software Engineering & Architecture. Als het echt een design topic gaat worden wordt dit topic verplaatst.

[ Voor 15% gewijzigd door Creepy op 06-08-2007 12:41 ]