Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Header Footer expect profile to be in pod url domain #124

Open
bourgeoa opened this issue Feb 26, 2022 · 6 comments
Open

Header Footer expect profile to be in pod url domain #124

bourgeoa opened this issue Feb 26, 2022 · 6 comments
Assignees
Labels
bug Something isn't working

Comments

@bourgeoa
Copy link
Contributor

bourgeoa commented Feb 26, 2022

@theRealImy
Pods on NSS are usually set on the url domain : http://solidos.solidcommunity.net/
this is not the case on CSS https://solidweb.me/test/

We have the following errors

GET http://localhost:3000/profile/card 404 (Not Found)
u @ fetchFactory.js:35
await in u (async)
(anonymous) @ fetchFactory.js:98
fetch @ Session.js:50
(anonymous) @ solidLogicSingleton.js:68
(anonymous) @ solidLogicSingleton.js:52
(anonymous) @ solidLogicSingleton.js:33
(anonymous) @ solidLogicSingleton.js:27
o @ solidLogicSingleton.js:23
fetch @ solidLogicSingleton.js:65
value @ fetcher.js:968
value @ fetcher.js:815
value @ fetcher.js:803
(anonymous) @ headerFooterHelpers.js:98
u @ runtime.js:63
(anonymous) @ runtime.js:294
(anonymous) @ runtime.js:119
n @ asyncToGenerator.js:3
s @ asyncToGenerator.js:25
(anonymous) @ asyncToGenerator.js:32
(anonymous) @ asyncToGenerator.js:21
p @ headerFooterHelpers.js:141
t.getPodOwner @ headerFooterHelpers.js:74
(anonymous) @ index.js:62
u @ runtime.js:63
(anonymous) @ runtime.js:294
(anonymous) @ runtime.js:119
n @ asyncToGenerator.js:3
s @ asyncToGenerator.js:25
(anonymous) @ asyncToGenerator.js:32
(anonymous) @ asyncToGenerator.js:21
l @ index.js:79
t.initFooter @ index.js:36
t.createFooter @ footer.js:17
(anonymous) @ index.js:39
u @ runtime.js:63
(anonymous) @ runtime.js:294
(anonymous) @ runtime.js:119
o @ index.js:14
s @ index.js:16
Promise.then (async)
o @ index.js:14
s @ index.js:16
(anonymous) @ index.js:16
(anonymous) @ index.js:16
l @ index.js:49
t.default @ index.js:19
(anonymous) @ index.ts:32
Promise.then (async)
l.panes.runDataBrowser @ index.ts:31
(anonymous) @ ?code=4820Eq1wrLU-HUOmq24ui7CAtpMnc0zZbiZyf2hUJ6I&state=303f986d42cd4b6b8dc23115cbbd9634:2
Show 9 more frames
headerFooterHelpers.js:114 Uncaught (in promise) Error: Did NOT find pod owners profile at <http://localhost:3000/profile/card#me>
    at headerFooterHelpers.js:114:19
    at u (runtime.js:63:40)
    at Generator._invoke (runtime.js:294:22)
    at Generator.throw (runtime.js:119:21)
    at n (asyncToGenerator.js:3:20)
    at l (asyncToGenerator.js:29:9)
@bourgeoa bourgeoa changed the title Header Footer expect profile to be in in url domain Header Footer expect profile to be in pod url domain Feb 26, 2022
@jeff-zucker
Copy link
Collaborator

How can we know whose pod we are on? If we know the WebID, we look in the profile for a pim:storage triple. If we don't, we can look in the root container for a pim:Storage triple. Then we see if our current location is within one of those. It's possible that both of those are missing, in which case the only way is to guess by assuming a given domain/container structure and that may fail. If we don't know the WebID, we can't be guaranteed of finding the profile. So SolidOS should never fail when it can't find the profile. It might warn or refuse to perform certain actions, but it should not fail.

@jeff-zucker
Copy link
Collaborator

And we can't make the assumption that we will always know "whose pod we are on".

@timbl
Copy link
Contributor

timbl commented Mar 3, 2022

The way to find the top boundary of the pod is to check the folders at each path (from top or bottom but bottom probably best to avoid unauthorized errors) to find one which declares itself to be a solid:Storage in the body RDF. IIRC that is the current protocol.

@csarven
Copy link

csarven commented Mar 3, 2022

https://solidproject.org/TR/2021/protocol-20211217#storage is the relevant section where there is a server requirement to advertise a Link relation type Storage and client requirements to discover the storage in which a resource is part of - essentially given a URL, check its headers for the link relation, if not found, check its container's headers all the way to root container until found.

@timea-solid
Copy link
Member

Duplicate ticket: #128

@timea-solid
Copy link
Member

This seems to be a fix in SolidOS and in the server too. The protocol can help to some extend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Development

No branches or pull requests

5 participants