SolidLabResearch / generic-data-viewer

Generic query-based data viewer
MIT License
0 stars 0 forks source link

Proxy fails with localhost #76

Closed pheyvaer closed 1 year ago

AronBuzogany commented 1 year ago

Isn't this because localhost "loses" its meaning when redirected through the proxy? Should I try first without proxy and if it fails with, don't think hard coding localhost is the proper solution

pheyvaer commented 1 year ago

Can't we set up a proxy on localhost as well? This would make it more reliable for tests as well.

AronBuzogany commented 1 year ago

I guess we could do that, but if the proxy is changed in the config file, the same error would occur again making it not so configurable

pheyvaer commented 1 year ago

What do you mean? It has to work for us for our tests. And the option still remains in the config file. The end-user has to make sure that their proxy works for their use cases. They also have to make sure that their queries work on their data sources.

AronBuzogany commented 1 year ago

@pheyvaer I have added a local proxy on the local-proxy branch with cors-anywhere. It has resolved both this issue, and the original one. However there is now another:

When trying to do an authenticated fetch, I get a 401 or 403 even though I know I am authenticated (without proxy it works). On the server side (local CSS in this case) I get the following warning/error:

2023-08-08T06:25:30.128Z [DPoPWebIdExtractor] {Primary} warn: Error verifying WebID via DPoP-bound access token: The DPoP proof htu parameter must be the HTTP request URI without query and fragment parts.
Actual: http://localhost:8080/example/favourite-books
Expected: http://localhost:8000/http://localhost:8080/example/favourite-books

My best guess of what's going wrong is that the authentication headers are set for the proxy url, but I have been looking into this for some time now and I don't seem to be able to figure it out.

AronBuzogany commented 1 year ago

If trying locally run npm run start:proxy to start the proxy

pheyvaer commented 1 year ago

Interesting! Would it be a solution to have a parameter per query to enable/disable the proxy? That way we can enable it for servers with issues and disable it for resources that are on pods?

AronBuzogany commented 1 year ago

Would it be a solution to have a parameter per query to enable/disable the proxy?

Can't immediately think of a case where this won't work. I have adjusted it accordingly and opened a PR #78 . By default, no proxy is used.