For creating new user accounts, we have a very important UX requirement to be able to let a user click on register a new account from the app, and instead of then redirecting to a generic login page, to go directly to the registration page on the Pod Server. Believe it or not, many people cant figure out to press register again at that point.
So my question is, with solid-client-authn-browser, is there a login option that would allow sending a k/v to the server so that the server would then route directly to the registration page instead of the generic login page?
And then you want the user to be redirected to the Pod Server, to create an account there ? Would that mean to provision a Pod for the newly created identity on the Solid Identity Provider ?
I don't think
solid-client-authn-browser is going to have the options that you need, because (if I understand correctly), you are designing UX around creating a user account on the Solid Identity Provider and/or the Pod server, which is out of the scope of solid-client-authn-browser. As a matter of fact (and as surprising as it may be), it's even out of the scope of OIDC :)
@NSeydoux The use case is from an application, the user able to click a "Register New Pod" button that would then go right to the registration page on the Pod Server rather than having to start at a login page on the server. So we can't use the init parameter with login to send info to the server?
So this would be a user on our TrinApp going straight to registration of a new pod. In the case of TrinPod, it is both an IDP and Solid Server, so we can work with anything we can get from the app to send the user direct to /registration
@gibsonf1 (Fred Gibson) Any reason a regular
<a href="https://trinpod.us/registration">Get a Solid Pod</a> wouldn't work?
Hmm, I'm not sure what you mean - does trinpod.us not also function as the IDP? And what required authentication data are we talking about, if there's not even an account yet?
Ah... Maybe you're looking at having the user be logged in to the newly-registered account after registration?
I understand. Hmm... I'm not sure whether that's something solid-client-authn would add if there's no spec-prescribed standardised way to pass data to the IDP on login - in fact, it seems like a use case you might want to bring up for the spec, specifically passing some kind of indication that the IDP should initiate a registration flow.
@gibsonf1 (Fred Gibson) That's a good question that I unfortunately don't know the answer to. I'm sure someone in solid/specification will be able to point you in the right direction though :)
For fellow Vue devs using solid-client-authn-browser and solid-client, here is the revised store.js actions. In this scenario, you can just loadThing whenever you need a thing, and then it will automatically create a new datastore if one isn't there already:
actions: {
async loadDataSet ({state}, uri){
uri = u.getURI(uri)
if (uri){
var ds = state.dataSets[uri]
//add head ping etc here to check if any server changes
// set ds to null if changes happened
if (ds){
return ds
} else {
var currentThing = state.things[uri]
var ds = await client.getSolidDataset( uri, {fetch: window.solid.session.fetch})
var dsUri = client.getSourceUrl(ds)
if (currentThing){
currentThing.dataSet = dsUri
Vue.set(state.things, uri, currentThing)
}
var things = client.getThingAll(ds)
$.map(things,function(thing){
thing.dataSet = dsUri
Vue.set(state.things, client.asUrl(thing), thing)
})
Vue.set(state.dataSets, dsUri, ds)
return ds
}
}
},
async loadThing ({state}, uri){
uri = u.getURI(uri)
if (uri){
var thing = state.things[uri]
if (thing){
return thing
} else {
var ds = await dispatch('loadDataSet',uri)
thing = state.things[uri]
return thing
}
}
},
Here is a new version for Vuex that integrates solid-client with rdflib to get the best of both worlds:
actions: {
async loadDataSet ({state}, uri){
uri = u.getURI(uri)
if (uri){
var ds = state.dataSets[uri]
//add head ping etc here to check if any server changes
// set ds to null if changes happened
if (ds){
return ds
} else {
var currentThing = state.things[uri]
var ds = await client.getSolidDataset( uri, {fetch: window.solid.session.fetch})
var dsUri = client.getSourceUrl(ds)
var dsNode = $rdf.sym(dsUri)
if (currentThing){
currentThing.dataSet = dsUri
Vue.set(state.things, uri, currentThing)
}
var things = client.getThingAll(ds)
if (things){
$.map(things,function(thing){
thing.dataSet = dsUri
thing.quads.forEach(function(quad){
var newObject
var qObject = quad.object
if (qObject.constructor.name === "Literal"){
newObject = new $rdf.Literal(qObject.value,qObject.language,qObject.datatypeString)
} else {
newObject = $rdf.sym(u.getURI(qObject))
}
rdfStore.add($rdf.sym(u.getURI(quad.subject)),
$rdf.sym(u.getURI(quad.predicate)),
newObject,
dsNode)
})
Vue.set(state.things, client.asUrl(thing), thing)
})
}
Vue.set(state.dataSets, dsUri, ds)
return ds
}
}
},
@gibsonf1 that's a good point, and a very valid use case, but @vinnl:matrix.org is correct: that's kind of outside of the current scope of solid-client-authn-*, and is likely to be so until the spec mandates something for this. Do you think solid/specification#152 describes what you would need ? If so, can you comment on it with your use case so that it gets more attention, and otherwise, could you create an issue on that repo where we could carry on the discussion ?
@NSeydoux solid/specification#152 looks quite good, once we're out of an immediate launch crunch, I'll work to explain our use case and how that relates. For sure the process is far easier for the user when IdP and PS are on the same server as in the TrinPod case.
A quick solid-client question. How would one go about getting all quads where a given uri is the object of the quads?
@gibsonf1 (Fred Gibson) Sorry, I missed this in between your code samples :) What exactly are you trying to do? In solid-client you don't tend to work on individual quads, but on Things (i.e. sets of quads with the same subject). So for example, if you wanted all Things of a given type, you'd do something like this:
const bookmarks = getThingAll(resource).filter(thing => getUrl(thing, rdf.type) === bookmark.Bookmark);So here you get sets of quads with the same subject, for each of which at least one has the URL of bookmark.Bookmark as the object and the URL of rdf.type as the predicate.
@vinnl:matrix.org Basically I want to know what things link to this thing (essentially, where the thing I'm interested in is the object of the triple, so I can know what subject of the triple is linking to the thing). It seems solid-client is currently not set up to support relationship traversals between things like this, so I just added rdflib into the mix, which is great at it. To support inter-thing traversals, solid-client would need a similar repository idea to rdflib where all quads are available to query (from the various things) such that you could understand those links.
@gibsonf1 (Fred Gibson) How about this?
const thingsLinkingToTargetThing = allThings.filter(thing => getUrl(thing, "https://your.vocab/predicate", targetThing)?
(But then without the missing closing bracket :) )
I see your point, I could just build allThings myself with the load
if that were part of solid-client with some cool apis to get things out, that would be highly helpful
The problem with using rdflib and solid-client is that they have incompatible object types, so there is a doubling of memory needed
Probably the best answer is to build a true graph in the browser where the Things basically interface between that graph and the Solid Server such that you could traverse that graph in powerful ways with the app. This is what we do on the Server side. I don't think rdflib is a true graph, but simulates one with queries.
We are using https://visjs.org/ for network graph visualization now, so I guess we have 3 different representations happening in the app, but the vis data structure is a true graph
Yeah I was using
allThings to refer to the cache of Things you are building in your Vuex store.
@acoborn just recommended that spec compliant state parameters be user to communicate with the IdP server during login with solid-client-authn-js: >@acoburn
I would take it up with the authors of that library. Ask them to add support for state parameters. It is part of the OAuth2 protocol
See https://tools.ietf.org/html/rfc6749#section-4.1.1
I would take it up with the authors of that library. Ask them to add support for state parameters. It is part of the OAuth2 protocol
See https://tools.ietf.org/html/rfc6749#section-4.1.1
Right now we are using query parameters in the redirect url to communicate to the server (for example, to start on the registration insteaad of login with start=registration )
@gibsonf1 (Fred Gibson) I think feature requests are best logged here, if they're not logged already: https://github.com/inrupt/solid-client-authn-js/issues/new?assignees=&labels=enhancement&template=feature_request.md&title=
