oslc / oslc-browser Goto Github PK

Some ideas on future features:

• Click empty space to unselect all nodes in a graph
• select a graph node and:
  • Show preview - works but needs to use portal to decouple rendering the graph from rendering the dialog
  • Edit (title, if title is displayed)
  • Hide/Unhide (depending on Hide toolbar button and whether the node is hidden)
  • Hide type
  • expand/collapse
  • Remove (from graph)
  • Delete (from repository)
• multi-select nodes and:
  • Hide
  • Hide type
  • expand/collapse
  • Remove
  • Delete
• Select two nodes and add link
• Select an edge and:
  • Hide
  • Hide type
  • Delete
• Click toolbar Hide button to toggle show/hide on/off.
  • Hide off: all hidden nodes are displayed in the graph
• New… create a new impact analysis graph optionally using a template
• Template specifies graph parameters that override the defaults
  • traversal: incoming, outgoing, both, default: outgoing
  • depth: number of link traversals to include in the graph, default: 1
  • layout: how the graph should be laid out, default: Dagre layout
  • style: node and edge styles, default: explorer-styles.css
• Save As… save the current graph as an impact analysis diagram
• Save… save a previously saved graph
• Save as Template… save the current graph as a template for creating new graphs

Can we provide a resource URI as a HTTP parameter, so the app starts with that resource already fetched and displayed?

Maybe there's a problem with the quality factor is not specified or is the same, servers seem to return application/rdf+xml. Accept="application/x-oslc-compact+xml;q=0.5,application/rdf+xml;q=0.4" seemed to work for DNG, but maybe it doesn't for RTC.

Without disabling any Chrome security:

1. Header set Access-Control-Allow-Headers "Content-Type, OSLC-Core-Version" (Apache) needs to be added so that JS code can send OSLC-Core-Version header (as per https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers) as well as use non-common Content-Type such as RDF (see https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_request_header#Additional_restrictions as to why)
2. Header set Content-Security-Policy "frame-ancestors 'self' *;" + Header set Access-Control-Allow-Methods "GET, POST, OPTIONS" allows other websites to use an OSLC client to talk to their endpoint as well as to embed their delegated UIs in an IFRAME.
3. Header set Access-Control-Allow-Credentials "true" allows cookies to be forwarded by the browser on JS requests. However, this feature does not allow a '*' in Access-Control-Allow-Origin. The server MUST reply Access-Control-Allow-Origin: http://localhost:3001 if it wants to let the browser pass auth cookies along with an OSLC Client JS request from that page. This is the only thing that cannot be done via "server config" and shall be done in the response phase of the OSLC server.

https://polarion.oslc.itm.kth.se/polarion/oslc/services/catalog returns 200, for example and gives you a login page.

One approach is to request https://polarion.oslc.itm.kth.se/.well-known/resource-that-should-not-exist-whose-status-code-should-not-be-200 beforehand (see protocol-registries/well-known-uris#13 and oslc-op/oslc-specs#460) but it only shows if the server is completely off its meds.

Should we go radical and consider any non-RDF response to be an error?

@jamsden @jadelkhoury

The redirects in request.authGet() are not working when request.js is used in the browser. Authentication challenges need to be handled by the browser, not the oslc-client.

Work around: login to the CE tools using the browser before attempting to access resources through the oslc-browser web app. The browser will automatically provide the necessary authentication tokens from the user’s session.

See solid-auth-client and profile viewer tutorial for information on how to use rdflib in a browser based application.

Another option might be to explore other options for request.js that work in Node.js and the browser, while also providing the authentication options we need (Basic, Digest, JEE Form, OAuth 1.0a, OpenIDConnect).

RTC users a lot of these and they cause serialization errors. There are currently being filtered out of the OSLCResource as a work around.

Can’t get select or unselect to work to do the highlighting, so there’s no way to unhighlight all the nodes when clicking on empty space. There’s no tap event on the graph that I can find.

Just ran npm install (updated README, btw), got this:

added 1743 packages from 975 contributors and audited 1817 packages in 105.799s

20 packages are looking for funding
  run `npm fund` for details

found 2056 vulnerabilities (885 low, 18 moderate, 1152 high, 1 critical)
  run `npm audit fix` to fix them, or `npm audit` for details

I am curious whether I shall laugh about 1743 deps or cry about 1152 high sec issues?

Getting a CORS error: When running the oslc-browser web app in a different container than the IBM jazz-apps, there will be a CORS error on GET of a IBM ELM resource.

It is possible to configure WebSphere Liberty or Tomcat to enable CORS. Configuring Cross Origin Resource Sharing on a Liberty server should be used for production

Work around: run oslc-browser using https and disable CORS checking in Chrome:

open -n -a Google\ Chrome --args --disable-web-security --user-data-dir
HTTPS=true npm start

Open any ELM resource in order to login and store the authentication tokens in the browser.

Need to configure the App.js to:

1. support https, SSL, and prompt to accept the self assigned certificate (like the browser does.
2. handle CORS challenge
3. Add support for OpenIDConnect to that can be added as a friend to DNG.
4. Or maybe try adding as a whitelist URL in DNG

https://example.com:9443/rm/rootservices: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

var myRequest = new Request('flowers.jpg');
var myMode = myRequest.mode; // returns "cors" by default
myRequest.mode = 'no-cors'; // might work ok, but probably not for PUT or POST.

Might be able to use an express middleware component to do this.

After managing to get OSLC Browser to work on OSLC CM RefImpl server (via #18; oslc-op/refimpl@66527f6; oslc-op/website-content-negotiation#8), I have gotten this output:

I am trying to understand now how this browser is to be user and what is its utility? It does not seem to handle RootServices, and does not list the SPC properly. I got a bit further with the linked resources from RefImpl:

Questions:

1. Is that it? Or am I holding it wrong™?
2. Do we have any interest in improving it? I was thinking to at least upgrade some dependencies and then jumped off my seat when I saw #15.
3. @jadelkhoury and @axelreichwein what do you think about OSLC in the browser in general? You had first-hand experience with https://github.com/kth-mda/oslc-schema-viewer (+https://github.com/kth-mda/slviewer and https://github.com/kth-mda/rdfexplorer) and https://github.com/koneksys/KLD. I personally see 3 promising things:
   1. Solid is pushing RDF/LDP on the web and they are not suffering from our CORS/CSP misery.
   2. WebComponents spec is essenntialy IFRAME 2.0 for 2020 web and given OSLC's most popular feature is DUI, we are ought to look into it.
   3. I hear about more and more modelling tools moving to the web itself, including https://github.com/eclipse-sirius/sirius-web