Solid Auth met LDflex uitzoeken

[marcvanandel]

Private resources kunnen niet worden gelezen ... terwijl er wel een sessie beschikbaar moeten zijn. Is dit wel goed werkend in de LDflex lib? Zijn hier al issues voor opgevoerd op het Solid Forum?

[kad-busses]

We maken nu gebruiken van @solid/query-ldflex, welke niet is geupdate sinds 2020. Onder de motorkap maakt die gebruik van https://github.com/nodeSolidServer/solid-auth-client voor de authenticatie, welke echter alleen nog voor legacy gebruikt wordt. Wanneer we in de applicatie ingelogd zijn met @inrupt/solid-client-authn-browser is dat blijkbaar een andere sessie dan die van solid-auth-client. Vandaar dat private resources niet bereikbaar zijn.

Om bij private resources te kunnen, zouden we kunnen kijken of we gebruik kunnen maken van https://github.com/comunica/comunica-feature-solid/tree/master/engines/query-sparql-solid, waar actieve ontwikkeling aan is, al is dat geen ldflex. Lijkt er niet op dat we de Comunica Engine binnen @solid/query-ldflex kunnen vervangen met de nieuwe.

Met andere woorden, het lijkt lastig te worden om met LDFlex bij private resources te komen. We kunnen denk ik a) geen ldflex gebruiken, maar direct Comunica engine, vergelijkbaar met hoe we nu KKG bevragen, of b) de bestanden in de pods openbaar maken, zodat we ldflex kunnen gebruiken. In dit geval kunnen we onderzoeken hoe we de ACL kunnen zetten van de containers die we aanmaken, of c) wellicht een andere optie?

[marcvanandel]

Interessant! Ik zat op een vergelijkbaar spoor ... naar @inrupt/solid-client-authn-browser waarvan we de fetch gebruiken ... dus zou het moeten werken. Ik had nog niet gezien dat onze sessie gebaseerd is op de verouderde solid-auth-client ... maar dat verklaart veel 😏

Ik zag ook al dat de ldflex/query-solid ... nou niet echt super veel toevoegt tov rdflib zoals wij 'm gebruiken ... waarbij bij mij ook al de vraag rees of ldflex zelf nu wel zoveel toevoegt. Dus een proef met direct gebruik van óf rdflib óf comunica vind ik niet zo gek. Wat ldflex dan precies toevoegt, is mij nog niet scherp.

Het geeft mij wel weer aan dat er diverse libs in het ecosysteem zijn die in ontwikkeling zijn ... en vooral verschillend. Vaak sluiten ze op elkaar aan ... maar niet in ontwikkeling en dus is de combinatie van libs vaker problematisch dan behulpzaam. Vind je niet?

[marcvanandel]

Hmm... vandaag toch wat tijd gestoken in het werkend proberen te krijgen met nieuwere versies van de comunica libs ... en indirecte dependencies ... maar #nodemoduleshell brook loose! 😳 Niet een prettige plek om te zijn ... 😏

Ik denk dat we het beste een issue bij LDflex kunnen opvoeren ... en dan zonder LDflex - dus met Inrupt libs - verder gaan?

[marcvanandel]

OK. Issue aangemaakt: LDflex/Query-Solid#73

[marcvanandel]

Ik stel voor om LDflex voor nu te laten vervallen en helemaal uit de applicatie te halen. Laten we gebruik maken van de meer up-to-date zijnde Inrupt libs. Wat daar minder mooi aan is, is dat het geen SPARQL (of GraphQL) gebruikt en dus is het LinkedData gedeelte in de applicatie ... 'wat zuinig' ... maar we kunnen we ervoor zorgen dat de output die we opslaan in de PODs wél valide is.

Eens?

[marcvanandel]

OK. We gaan toch door met LDflex ... en dan zonder authenticatie. Dat betekent dat we in onze solid-pod-provider access controls instellen waarbij alle events leesbaar zijn voor ingelogde gebruikers. Dan lijkt het wel goed te werken.

We hebben voor onszelf aangetoond dat authenticatie en autorisatie werkt in de Solid Spec en Solid Community Server ... maar we hebben er nu last van dat LDflex de laatste versie van de Inrupt Auth lib niet ondersteunt. Dit lijkt een bekend fenomeen te zijn in de LinkedData en Solid libraries: verouderde libs lopen te ver achter, voorbeelden van specs zijn verouderd en/of specs zijn nog te veel in Draft cq veranderen nog te veel en libs zijn nog niet bij met de laatste versies van de specs. Dit maakt ontwikkelen lastig en minder plezier dan nodig en zou moeten.

Voor nu gaan we dus door met LDflex, nemen minder private toegang voor lief voor onze demonstrator.