Open fschade opened 1 year ago
Hey thanks for asking about this. It's a neat idea. I have a few reservations about this and I wanted to explain them and let you know that we're thinking about it and our current thoughts.
Specifically if we export everything then everything is theoretically subject to stability guarantees not just the user facing portion. We'd have to look at what specific interface we export. For example what specific entry location is most desirable to you? We'd rather not constrain our development in this process so we'd have to consider that aspect too (i.e. rather not have to bump major versions regularly or prevent us from making a change specifically for the sake the exported members are changing).
We had in mind exporting a number of interfaces so that plugins could eventually be made. Maybe this addresses an element of it.
@james-d-elliott thanks for detailed explanation and sorry for late reply, too many things on my plate right now.
I totally get your point, make sense to me, as soon as you expose something its harder to change the implementation and keep the public api intact.
we're not here for free snacks, instead we're interested to help on certain things, we could for example come up with contributions, but thats just me, i have to discuss it with my team-lead, but i expect green light since we're also doing open-source and thats how it works (or should).
if i'm not wrong my colleague @rhafer already had a look. Lets stay in touch!
Staying in touch sounds good to me regardless, from what I have seen we have a lot of users of your product. I'm wondering if instead of exposing all of internal we can be targeted in what we expose based on your requirements since that's likely to match the requirements of someone else.
if i'm not wrong my colleague @rhafer already had a look. Lets stay in touch!
Yeah, that's correct. I am currently looking into this to figure out what we'd need. And I agree, exposing all of internal
shouldn't be the goal here.
Staying in touch sounds good to me regardless, from what I have seen we have a lot of users of your product. I'm wondering if instead of exposing all of internal we can be targeted in what we expose based on your requirements since that's likely to match the requirements of someone else.
Basically what we need exposed minimally would be some methods, that allow to inject a configuration and start authelia using that configuration from within ocis. I've already come pretty far with just exposing the internal/commands
interface and inject the configuration as a config map via ConfigSetDefaultsRunE
. This isn't an exactly nice interface, but it got me started. It might work to turn this into something similar to etcd's embed
package (https://pkg.go.dev/go.etcd.io/etcd/server/v3@v3.5.9/embed)
I am about to push my (still rough) changes to ocis and authelia to a fork to give you an idea about what we've done so far.
This contains my current changes to authelia: https://github.com/rhafer/authelia/tree/ocis-embed (it's really just exposing the internal/commands
package.
And here's the changes needed for ocis to actually embed authelia: https://github.com/rhafer/ocis/tree/authelia-experiment Currently still in a very rough way, using a mostly hardcoded config. But you'll get the idea.
Gotcha. We can probably work with this or something similar, will discuss with the team. Are there any particular commands that you're aiming to leverage? Assuming the root daemon cmd? Or is it more than that?
Gotcha. We can probably work with this or something similar, will discuss with the team.
Cool, thanks. Please keep me posted.
Are there any particular commands that you're aiming to leverage? Assuming the root daemon cmd? Or is it more than that?
Not sure yet. We might also need stuff from the "storage" command, I guess.
Just letting you guys know I've not forgot about this. I'll try to dedicate some time to setting up a POC with the intent to merge once you've tested it.
Sorry guys for taking so long. Going to look at this over the weekend. Is there a means of communicating with one of you familiar with the goals and integration needs that I can discuss this with over a real time channel?
@james-d-elliott we're regulary hanging out in the ownCloud Infinite Scale room (https://matrix.to/#/#ocis:matrix.org) in matrix. I am also available in the authelia space. Would that be a good starting point?
Description
we are interested in using authelia, since everything is currently in internal, we are not able to import and embed it.
Use Case
Make authelia our default (embedded) authentication provider.
Details
At the moment there is no way to use authelia from the outside, the only entry point is the cmd folder which imports from the internal commands package.
No response
Documentation
No response
Pre-Submission Checklist
[X] I agree to follow the Code of Conduct
[X] I have checked for related issues and checked the documentation