This HTML5 document contains 75 embedded RDF statements represented using HTML+Microdata notation.

The embedded RDF content will be recognized by any processor of HTML5 Microdata.

Namespace Prefixes

PrefixIRI
n4http://ods-qa.openlinksw.com/about/id/entity/http/ods-qa.openlinksw.com:8896/about/id/entity/https/forum.solidproject.org/t/pod-authentification-from-another-server-not-solid/
n62018-11-09T22:09:
pwdrhttp://www.w3.org/2007/05/powder-s#
schemahttp://schema.org/
n9http://ods-qa.openlinksw.com:8896/about/id/https/forum.solidproject.org/t/pod-authentification-from-another-server-not-solid/
rdfshttp://www.w3.org/2000/01/rdf-schema#
n8http://ods-qa.openlinksw.com:8896/about/id/entity/https/forum.solidproject.org/t/pod-authentification-from-another-server-not-solid/
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#
n2http://ods-qa.openlinksw.com:8896/proxy-iri/
xsdhhttp://www.w3.org/2001/XMLSchema#

Statements

Subject Item
n2:2a407d4a39053482ec9bd55d5151863f6a4774f5
rdf:type
schema:DiscussionForumPosting
schema:datePublished
n6:15Z
pwdr:describedby
n4:494 n8:494 n9:494
schema:author
codenamedmitri
schema:position
#4
schema:articleBody
Got it. So, the easy (though not exactly optimal) short-term answer is to have the application log in using those credentials, via the /login endpoint, and then just use the obtained cookie with its requests. For an example of how to do that in code, take a look at the performLogin function in solid-cli (that function uses username + password credentials, but the same logic would apply with a WebID TLS certificate as credential). The proper way to do this would be… well, it depends. There’s two basic options that come with trade-offs: 1 - User Token approach A long-lived WebID-OIDC access token, which is a mechanism where a user delegates access to the app. This is a common pattern with app delegation; for example, Facebook calls this User Access Token. The benefit of this approach is that the app itself does not store the user credentials. The downside is that a human has to be involved (at least during app setup) to enter in their credentials. This is kind of like whole-disk-encryption – it’s great, and secure, but it’s annoying that a sysadmin has to be present every time the server reboots (to enter in the encryption password). This option can be done right now, with no alterations to Solid Server. (although we can probably add a nicer UI for a developer to register their own app). 2 - App Token approach Giving an app its own credentials, its own identity. For example, Google does this with their Service Accounts (see their guide on Server to Server Applications), and Facebook does this with App Access Tokens. The benefit of this approach is - again, the app does not store user credentials, and it’s possible to have fine-grained permissions just for the app, separate from the user. But that’s also the downside, since you have to modify your ACLs to specifically give access to the app. (Notice that both Google and Facebook specifically limit what an app access token can do, it has many fewer privileges than a user token.)
schema:interactionCount
UserComments:0 UserLikes:1
schema:headline
POD Authentification from another server (not solid)
Subject Item
n2:eae9e920d0ca3cbf0d6c1a7c0582f42923df3e76
rdf:type
rdf:Statement
rdfs:label
Embedded HTML5 Microdata Statement 8
pwdr:describedby
n4:494 n8:494 n9:494
rdf:object
Got it. So, the easy (though not exactly optimal) short-term answer is to have the application log in using those credentials, via the /login endpoint, and then just use the obtained cookie with its requests. For an example of how to do that in code, take a look at the performLogin function in solid-cli (that function uses username + password credentials, but the same logic would apply with a WebID TLS certificate as credential). The proper way to do this would be… well, it depends. There’s two basic options that come with trade-offs: 1 - User Token approach A long-lived WebID-OIDC access token, which is a mechanism where a user delegates access to the app. This is a common pattern with app delegation; for example, Facebook calls this User Access Token. The benefit of this approach is that the app itself does not store the user credentials. The downside is that a human has to be involved (at least during app setup) to enter in their credentials. This is kind of like whole-disk-encryption – it’s great, and secure, but it’s annoying that a sysadmin has to be present every time the server reboots (to enter in the encryption password). This option can be done right now, with no alterations to Solid Server. (although we can probably add a nicer UI for a developer to register their own app). 2 - App Token approach Giving an app its own credentials, its own identity. For example, Google does this with their Service Accounts (see their guide on Server to Server Applications), and Facebook does this with App Access Tokens. The benefit of this approach is - again, the app does not store user credentials, and it’s possible to have fine-grained permissions just for the app, separate from the user. But that’s also the downside, since you have to modify your ACLs to specifically give access to the app. (Notice that both Google and Facebook specifically limit what an app access token can do, it has many fewer privileges than a user token.)
rdf:predicate
schema:articleBody
rdf:subject
n2:2a407d4a39053482ec9bd55d5151863f6a4774f5
Subject Item
n2:416092c784978684012fa3b4e1e014aa4a95e584
rdf:type
rdf:Statement
rdfs:label
Embedded HTML5 Microdata Statement 9
pwdr:describedby
n8:494 n9:494 n4:494
rdf:object
codenamedmitri
rdf:predicate
schema:author
rdf:subject
n2:2a407d4a39053482ec9bd55d5151863f6a4774f5
Subject Item
n2:8b833b6c13976b99d82e29fabe5b8e7c5836e3c6
rdf:type
rdf:Statement
rdfs:label
Embedded HTML5 Microdata Statement 10
pwdr:describedby
n8:494 n9:494 n4:494
rdf:object
n6:15Z
rdf:predicate
schema:datePublished
rdf:subject
n2:2a407d4a39053482ec9bd55d5151863f6a4774f5
Subject Item
n2:637201b340f3a45f4c18bbf4ba3d2198d888c1ca
rdf:type
rdf:Statement
rdfs:label
Embedded HTML5 Microdata Statement 11
pwdr:describedby
n4:494 n8:494 n9:494
rdf:object
POD Authentification from another server (not solid)
rdf:predicate
schema:headline
rdf:subject
n2:2a407d4a39053482ec9bd55d5151863f6a4774f5
Subject Item
n2:424dc397aeaa318ff94fcd4ec7fced8f0311ff56
rdf:type
rdf:Statement
rdfs:label
Embedded HTML5 Microdata Statement 12
pwdr:describedby
n4:494 n8:494 n9:494
rdf:object
UserComments:0
rdf:predicate
schema:interactionCount
rdf:subject
n2:2a407d4a39053482ec9bd55d5151863f6a4774f5
Subject Item
n2:e32b6b54738df22429f145388001e706ca0d5950
rdf:type
rdf:Statement
rdfs:label
Embedded HTML5 Microdata Statement 13
pwdr:describedby
n4:494 n8:494 n9:494
rdf:object
UserLikes:1
rdf:predicate
schema:interactionCount
rdf:subject
n2:2a407d4a39053482ec9bd55d5151863f6a4774f5
Subject Item
n2:fc97023247d35958047bbd4c7afbd0f84bf0b56f
rdf:type
rdf:Statement
rdfs:label
Embedded HTML5 Microdata Statement 14
pwdr:describedby
n4:494 n8:494 n9:494
rdf:object
#4
rdf:predicate
schema:position
rdf:subject
n2:2a407d4a39053482ec9bd55d5151863f6a4774f5
Subject Item
n2:3fa70c117424813a76336b2e8dea62b409417498
rdf:type
rdf:Statement
rdfs:label
Embedded HTML5 Microdata Statement 15
pwdr:describedby
n4:494 n8:494 n9:494
rdf:object
schema:DiscussionForumPosting
rdf:predicate
rdf:type
rdf:subject
n2:2a407d4a39053482ec9bd55d5151863f6a4774f5