Open colin-campbell opened 3 months ago
This is great! I also planned a similar feature after releasing OpenAI API-compatible support. The n4ze3m/page-share-app will be updated to include an admin panel where users can add their Ollama, Llama.cpp, or any OpenAI-compatible endpoint. It will then act as a proxy with role-based controls, etc., for the Page Assist extension
This is great! I also planned a similar feature after releasing OpenAI API-compatible support. The n4ze3m/page-share-app will be updated to include an admin panel where users can add their Ollama, Llama.cpp, or any OpenAI-compatible endpoint. It will then act as a proxy with role-based controls, etc., for the Page Assist extension
Love this idea.
I have a basic working version that has successfully authenticated against Keycloak OpenId Connect using Authorization Code Flow with PKCE from background.ts.
I had to "roll my own" using the WebCrypto API, https://www.w3.org/TR/WebCryptoAPI because MSAL, and other available libs are relying on node builtins which are playing havoc with the Vite config and are proving difficult to shim - vite-plugin-node-polyfills for example doesn't work for this use-case unless I am missing something.
I don't think it's a biggie, because of the simple flow ACF-PKCE being the only one really suitable for this type of application, and the available libs are over-engineered to the max to support all standard flows.
So just some scaffold to do around token expiry, refresh and collecting the config parameters, and I should have an experimental PR by the end of the week.
One question: I was thinking of keeping all that stuff hidden from the user unless the initial call to /api/tags returns 401 Unauthorized, then we should display a "sign in" button. What do you think @n4ze3m @therealtimex?
Of course centralising all this in some sort of proxy makes some sense, but having standalone operation with only the extension is a worthy effort too.
Why not adding a menu here:
I will of course add a menu for settings/endpoints there. But the auth itself should happen in the service worker using launchWebAuthFlow() which will take care of the authentication lifecycle without using the UI at all.
Wow, this is amazing! I'm pinning this issue as a v2.0.0 discussion.
I will of course add a menu for settings/endpoints there. But the auth itself should happen in the service worker using launchWebAuthFlow() which will take care of the authentication lifecycle without using the UI at all.
definitely
Since this plugin is generally available in the Chrome Web Store, it would be a real plus for businesses to have it useable over the Internet with proper authentication, authorisation and sign-in.
OpenID Connect, for instance is doable in a browser extension, but with some tricky things in the manifest around site access, etc. Maybe Microsofts MASL.js could help us here.
If there is enough interest here, I will try to make an implementation of this - it would be great for corporate users to be able have this installed through MDM and ready to go out-of-the-box with settings, as it were.
What do you think?