I decided to play around with the API after realizing it could accomplish things not yet supported by Fibery in the UI yet, and could even build a tool specific to my org to make it more useful.
My use case was to build a chrome extension to support quickly adding web references to Type within fibery as a starting point. This would give us some web-clipper type functionality. I have a proof of concept chrome extension setup with a settings area to input your token and fibery domain.
It is using a modified version of the unofficial js library, which I modified to utilize Axios (existing dependency is no longer supported). I’ll submit a merge request for this once I get it cleaned up a bit and working with file downloads/uploads.
Unfortunately, the last snag I have is that cross origin requests are being blocked.
Access to XMLHttpRequest at 'https://<domain>.fibery.io/api/commands' from origin 'chrome-extension://fodeaclafgkhegpjlghocggimclocibh' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
I’d appreciate it if this could be enabled, and I’m sure other would as well, since this could be shared with the community. Otherwise, I’ll have to host my own proxy server to proxy the requests.
I’ve asked around and turns out we were writing web clipper extension and it seems were able to make requests to the API.
And it had the following permissions:
Thanks, I went back and added these permissions and that doesn’t help. CORS is set from the server-side, so I don’t understand how setting any permissions in a chrome extension is going to help. There appears to be extensive work on Chrome’s part to block any manipulation of web requests to get around CORS, but if that was the approach you were taking at the time then you’d have to be requesting “webRequest” permissions.
From what I can tell, whether you perform the API query from the console of chrome’s dev tools or do so in the background.js process of a chrome extension, the requests are treated the same. In both cases, the Origin is being compared against what is allowed and it seems to only allow what you quoted in the permissions suggestions or by having no origin.
When initiating the request from the extension, the Origin is something like chrome-extension://fodeaclafgkhegpjlghocggimclocibh, which is why it fails. If I originate it from the chrome console on google.com, the same thing happens because origin of https://www.google.com doesn’t match *.fibery.io/ or .fibery.io/.
Hello, Oshyan!
Something is definetely being cooked
Nick, what you are saying definitely makes sense!
It is just that the following lines in permissions should have enabled CORS requests to the specified origins:
"https://*.fibery.io/",
"https://*.fibery.io/*"
Can you please confirm that you do have them in your extension and it still doesn’t work for you?
Requesting cross-origin permissions
By adding hosts or host match patterns (or both) to the permissions section of the manifest file, the extension can request access to remote servers outside of its origin.
{
"name": "My extension",
...
"permissions": [
"https://www.google.com/"
],
...
}
Thanks. Yes, they are added to the permissions list in the manifest file for the extension. I’m not sure what changed, but it does appear to be working now. Chrome might have been hanging onto an old manifest file, but i thought i had clicked refresh on it. Oh well, thanks for the help, and I’ll keep playing around with it. I have just a hardcoded call to create a simple entity from the background.js script, so I just need to get the data about the page.
I created an extension for our company to leverage data from the page to provide quick access to internal admin tools. This allows us to quickly get to where we can edit the data associated with the page, so I think the rest of this should be relatively simple work.
I’m thinking about a couple main use cases:
simple web bookmarker: (capture url, metadata, description, main image, etc) that sends the data to a configured Type. Likely would extend this further to capture any schema.org data.
web clipper: for things like capturing a screenshot of an issue and pushing that into some kind of configurable type. This is the area I don’t have much experience with and likely wouldn’t work on unless there is some kind of open source library I can find that handles most of it
configurable data extract tool: the other case i was thinking was when you use certain sites regularly that contain any kind of data associated with them that you want to parse and send to a specific Type. At first I was thinking I would just write the code to extract the things for our org, but I think it wouldn’t be too much more work to make this a generic tool for anyone to use. This would allow you to get pretty clean data (as long as you can define css or xpath selectors) directly into the fields of the type that you want them to go into
@itsu, I assume you’ve noticed, but wanted to mention in case you didn’t. The permissions you shared are for the v2 chrome extensions that will be unsupported at some point. I switched pretty early on after encountering the docs mentioning to use v3, but it still required a fair bit of rework to convert it over. There are different permissions, background page is now a service worker, and different APIs to use (scripting, storage).
I think I’m getting close to where a working version could be shared. The conversion to v3 took a bit of time to work through those snags. So far I am able to extract a robust set of page metadata across the various types (og, twitter), identify primary images even if one isn’t set in the metadata, and am stripping down the HTML content into markdown so it can be put into a rich text field. I just need to clean things up quite a bit, but here is a preview demonstration that seems to get the majority of the primary content.
Right, also have noted that Google will be phasing out Manifest V2 at some point. Havent’ even checked what’s the difference and how painful it would be to switch over. Thanks for highlighting some of the changes!
The conversion to v3 took a bit of time to work through those snags.
It’s quite often painful to make such transitions. And especially frustrating – hey, I had it working just find, why I have to rewrite it
Is it the result of configurable data extract tool in the screenshot? Nice job!
Yeah, I’ll share something within the next week or so. Have had other things that pulled me off of it temporarily, but should be soonish. It’ll be a bit rough in terms of configuration, but at least functional in getting basic page information like you see in that screenshot into a single configurable type.
There is definitely the opportunity to extend this into supporting multiple types and custom configurations given the underlying projects I’m leveraging, but will take a little work on the options page to pass that through.
I’d love to be able to setup a fibery workspace for a project like this and be able to share certain pages to the public
