Code of Conduct: https://github.com/solid/process/blob/main/code-of-conduct.md - Website: https://solidproject.org
For clarity, the redirect works fine when running the app locally, but it's when I try to run it on the ec2 server that it's failing on the 'await session.handleIncomingRedirect(window.location.href)' line as part of the 'handleRedirectAfterLogin' function (included in the tutorial code). I've tried building and running with both parcel and webpack but I'm getting the same error. Is it something to do with the solid-client-authn-browser that it can't be run on the aws server? Or is there something I'm missing in the configuration of the remote server? Sorry to bother but this is the last step before my project can be evaluated so any advice would help a lot
Hello Solid Community, I'm currently working on a sample SOLID UI app using Angular and I want to use the format JSON-LD, I'm using the following functions
import { getSolidDataset, saveSolidDatasetAt } from "@inrupt/solid-client"; so my stupid question, how can I use JSON-LD to get Data and save data in JSON-LD format? thanks a lot for your help
@odaper What you can do is use rdflib instead of solid client, and then you can use any rdf format: http://linkeddata.github.io/rdflib.js/doc/
9 replies
Our developer wrote some code that allows you to access your Solid Pod using Spring. I hope this can help Java developers out there. https://www.konsolidate.eu/stories/solid-spring
1 reply
Hey folks, experiencing a pretty serious bug with the universal access api in solid-client, and wanted to see if anyone else was seeing the same behavior or if I'm just using it wrong. I created a bug issue here: inrupt/solid-client-js#1549. Specifically, the setAccess methods seem to be throwing on nonexistant .acls, even though the documentation claims those functions will create an .acl if it doesn't exist.
Just a heads up, there's been some changes & bugs regarding refresh tokens and the Inrupt SDKs and compatibility with ESS / client identifiers — so for now you might see refresh tokens not being present and not working correctly if they are present. We're working on fixes at the moment
I don't think so, basically to get back a refresh token, you need to indicate that you want one back by sending grant_types when requesting the initial token (so grant_types of authorization_code and refresh_token in the client identifier document), further, the client identifier must be sent when using the refresh token, which we currently don't send, and we're working on a fix for.
that is, I think this behaviour is in the specs
but I suspect on the ESS front that some security settings changed recently, as refresh tokens had been working without the above; but to be spec compliant we must make changes to the SDK
@jeff-zucker apologies for the slow reply, I'm pretty sure NSS and CSS both implement client identifiers (i.e., the client sends a request to registration_endpoint to get a client_id & client_secret), so we do have a bug there which is that we're currently not respecting the client_secret_expires_at value — so we don't clean up expired clients, which leads to the errors of "invalid client_id", but testing on SolidCommunity.net, it looks like the expiry there is always set to
0, which means that the client doesn't expire — where as ESS expires clients after a certain amount of time (configurable)
sorry, correction: NSS and CSS don't support client identifiers, but instead use dynamic client registration, which always requests both
["authorization_code", "refresh_token"]
https://twitter.com/project_solid?lang=en but with Musk taking over , I am in favor of closing the account.
I think Timea wants someone to create a Solid-based version of Twitter :) Which I'm quite sure nobody has done, but as a close second, @aveltens has done some experiments making a Pod part of the Fediverse (i.e. readable from Mastodon): https://forum.solidproject.org/t/discussion-solid-vs-activitypub/2685/34?u=vincent
@timea-solid maybe take inspiration from how Tantek Çelik does their twitter: https://tantek.com/2022/080/t1/
there's also https://github.com/tantek/bridgy and https://github.com/microdotblog/indie-microblogging in a similar space
(you could probably do cool things with Next.js and pre-building public pages from all the items in your solid datasets by having https://nextjs.org/docs/basic-features/data-fetching/get-static-props and using client credentials)
Hi, i've done a bit more work on my solid task app; you can find it https://github.com/Julian-Cole/solid-task-app - if anyone is interested. It's basically another ui over Alain Bourgeois's simple task app; but it shows how 2 apps can look different but use the same data source. I apologise in advance of the bad code / bugs etc.
9 replies
Hi, i have a question: I'd like to authenticate to a (REST) API endpoint(s) (written with express.js) with a Solid identity. (Sort of like we authenticate to solid data pods with Solid identity all the time, but instead of data pod it's a custom API). Is there a library to take care of that, server-side?
what i tried
I've briefly tried out @solid/access-token-verifier (not successful, yet) and maybe somebody knows if it's the right choice and perhaps even has some tips or examples how to use it?
(i also looked at express-openid-connect, but it seems to expect a fixed issuerBaseURL, which doesn't work in Solid context with many issuers, otherwise it would be a perfect fit)
say it again in different words
In other words, we send an authenticated fetch request from our app to the API endpoint (perhaps using @inrupt/solid-client-authn-browser). The API receives the request.
Now, it should look at the authorization header, do the necessary talking with identity provider, or whatever business it needs to do, and tell us that it's a valid token and return the requester's webId, and clientId, or throw error otherwise.
We need a library that does the part written in italics. If it's already wrapped as express middleware, even better.
Thank you!
where do i want to use this?
I'd like to use it for solid index. It's a little server, you give it a uri, it looks at it and saves relationships (triples) it's interested in (into mysql database). Then others can find you and your things via these relationships, using a ldf server on top of the database.
I have it working (without auth) at https://index.ditup.org/inbox, the indexed data can be queried at https://index.ditup.org/ldf, and it's all used by https://solid.ditup.org (all in early stages of development).
36 replies
Non-authoritative answer: I've observed that the newer Solid servers (ESS and CSS) do include the solid:oidcIssuer property in the profile document. Profiles without it seem to be limited to the older NSS. Hopefully it will be standardized in due course by the team that manages this repo: https://github.com/solid/webid-profile/
I can't say whether your idea of adding it is a good interim measure for an application to take but I did manually add it to my own NSS-hosted profile the other day.
@nickform:matrix.org , yep we on that team are working on the issuer issue. Also, more to the immediate point, so is NSS : nodeSolidServer/node-solid-server#1680
@mrkvon (and all app developers) - we working on the profile spec would love to hear your implementation experiences with profiles - which predicates do you use to discover infrastructure? (odic:issuer, solid:storage, pim:preferencesFile, solid:publicTypeIndex, trustedApp, etc.)
3 replies
As I'm sure you know,
solid:storage was indeed one I used (as a basis for then adding things to solid:publicTypeIndex and/or solid:privateTypeIndex), and the fact that its presence apparently also can't be relied on (https://forum.solidproject.org/t/data-discovery-on-community-solid-server/4695/9) kinda was the final straw that caused me to give up on further app development for now. So looking forward to your work :)
Thanks for the reminder of an important point. The new spec should say that a user has the option to keep their storages private but in that case they should have a storage predicate in the preferencesFile so there should always be a storage predicate. If there isn't, apps may offer to add one and "fixer apps" (like SolidOS) will be encouraged to do so. So general apps can expect spec compliant profiles to have that information to the extent the app has a right to see it. Does that a) make sense b) solve the problem which caused you to give up?
Yeah, that would probably solve it. I should emphasise though that this issue by itself isn't the reason I've paused app development - it's the fact that there's very little I can rely on to remain stable and supported at this point in time, so I'm waiting for there to be a big player that has a contract with Inrupt to be providing Pods that work with any app the user wants, and apps that work with any Pods the user wants. When that happens, I'm expecting there to be more incentive to keep things working, even if they're not perfect.
Following along here but I don't understand this bit:
"If you sign as yourself on your own pod, you already have control because pod owners automatically have control..."
Isn't that what I'm doing every time I sign into any app? In other words, any app I sign in as has full control over my pod?
If I may interject, that speaks to the question of whether users are supposed to know their webid or their idp or (worst case) both. I don't think it's a good idea to require users to learn the significance of both of those concepts and to know when to use one rather than the other and I really think that the best to ask them to learn is their webid which is specific to them. For that to become the rule, oidcIssuer would need to be present in the car majority of profiles. If the profile doesn't have it, I think it's okay to fallback to asking for the idp directly and to offer to fix up the profile after authentication had succeeded.
How does the team working on discussing the web profile see it?
Well, Tim has created QR codes that can be in the profile and scanned to find the WebID, so that's one way to hide complexities from users. Our current thinking is that we will recommend that a well-formed profile has at least one solid:oidcIssuer triple and that if an app delegated to manage a user's pod discovers it doesn't have such a triple, it can prompt the user to login by supplying an IdP or picking one from a list of known providers, the app can then find the issuer in the redirect back from the login and write it to the profile.
Isn't finding a WebID in a QR code within the profile document a bit circular? How would I have found the profile document without knowing the WebID in the first place?
So you come to my site, scan my QR code, then you can come back anytime without knowing my actual WebID