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

Serving private HTML in an iframe #184

Open
jeff-zucker opened this issue Jun 4, 2024 · 9 comments
Open

Serving private HTML in an iframe #184

jeff-zucker opened this issue Jun 4, 2024 · 9 comments

Comments

@jeff-zucker
Copy link
Contributor

When SolidOS is served on an origin different from the pod it is accessing (for example the SolidOS Webapp or Data-Kitchen, panes that use Iframes for HTML (dokeli, human-readable) will require a second login even if the user is already logged in as owner of the data. The images below show that that dokeli pane won't show the private HTML but the source pane will. The main page login applies to the location of SolidOS, while the iframe origin is that of the imported page.

With the source pane, I believe we can solve this issue by doing an authenticated GET on the HTML, and then displaying it in an iframe using the srcDoc attribute rather than the src attribute. Using srcDoc means that the HTML is coming from the same origin as SolidOS so it should work even when SolidOS is on a different server. I am not sure if this solution would apply to dokeli.
iframe-1
iframe-2

@jeff-zucker
Copy link
Contributor Author

An additional issue related to this is that since dokeli is the default pane for HTML, this confusing screen is what will be shown first.

@jeff-zucker
Copy link
Contributor Author

A possible security issue - the HTML would inherit SolidOS permissions.

@jeff-zucker
Copy link
Contributor Author

The simplest solution is to make the source pane the default pane for HTML. We could also make the human-readable pane the default if we changed it so that it used an authenticated fetch + srcDoc + a sanitizing operation to deal with security concerns.

@timbl
Copy link
Contributor

timbl commented Jun 5, 2024

In general more readable views like formatted text should take precedence over raw views like plain text. I guess we treat all HTML files the same whether dokieli or not. Is that part of the problem?

@jeff-zucker
Copy link
Contributor Author

@timbl - it's the iframe that is the problem, not specifically dokeli - it impacts all HTML incuding in the human-readable pane too. Agree, we should prefer the most readable format first. One solution is to use srcDoc with a sanitized version of the HTML in the human readable pane and make it the default pane for HTML. That way, users would see the HTML page (minus javascript and web components) as the default view and if they want to edit, they can use either dokeli or the source pane.

@csarven
Copy link

csarven commented Jun 5, 2024

I'm not sure I quite understand the difference between the dokieli and source panes. While unauthenticated, when I input https://jeff-zucker.solidcommunity.net/private/hidden.html into Viewing field, I see the dokieli pane opening up (because it is set to default?) but the server returns a 401 with payload containing the SolidOS Web App HTML (which has JS etc.) and what I see is same as the screenshots you've shared. For the source pane, I get a 401 too and it looks like this:

image

Correct me if I'm misunderstood you but are you saying that while one may be authenticated from https://solidos.github.io/mashlib/dist/browse.html and can view https://jeff-zucker.solidcommunity.net/private/hidden.html with the source pane, it doesn't load up in dokieli pane?

I couldn't reproduce this as I've created https://csarven.solidcommunity.net/hidden.html and gave Read permissions to only myself. I was able to view it both dokieli and source panes. When I'm not authenticated, I get a 401 in both.


Regarding srcdoc, dokieli also uses that for certain data that's to be rendered inside the pre element. The contents are sanitized, in the case of pre it escapes but for loading a whole document, it would need to be more aggressive like with DOMPurify or similar libraries. They will however by default disable script and many other things so if any scripting is of interest, need to thread carefully. That aside, srcdoc should be fine for raw HTML but I'm not sure if I quite see that addressing the main problem of this issue - or at least I don't understand it. Like I said, dokieli and source panes seem to work for me when authenticated while it is not readable to anyone else.

But yes the contents in which that resource originates from is already fetched. So, it is not doing dynamic rendering (on page load) like with src.


Happy to discuss / share more notes on this elsewhere.. we are / will be going through all sorts of security stuff in dokieli soon / this year.


Aside: this seems like a bug ?

image

@jeff-zucker
Copy link
Contributor Author

@csarven wrote

I've created https://csarven.solidcommunity.net/hidden.html and gave Read permissions to only myself. I was able to view it both dokieli and source panes. When I'm not authenticated, I get a 401 in both.

Can you confirm that when accessed from the github webapp, you were able to see both the dokeli and source panes without logging in a second time in the dokeli pane?

@jeff-zucker
Copy link
Contributor Author

And that you used the webapp login button to login, not the dokeli one?

@csarven
Copy link

csarven commented Jun 5, 2024

Right, I only used the login from the top-level app at https://solidos.github.io/mashlib/dist/browse.html (nothing form the panes).

But right now I can't even reproduce anything.. it shows me as signed in but getting 401 on the hidden. I've cleared cache/local storage everything and tried.. still no go. Also in private mode. I'm getting the bug / screenshot that I shared at the bottom of my comment above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants