-
Notifications
You must be signed in to change notification settings - Fork 73
Implement solution for standalone ooth, api, next.js #40
Comments
of course, it would be ideal if an ooth standalone was dockerized, obviously related to pr #26 |
Hey @chase-moskal I think the most complex part of this (and the main reason why I haven't implemented this) is configuration. How do you configure your own version of ooth with your own plugins with their own configs, but pack it in a standardized docker image? I don't really know a good strategy to do this. |
@nmaro — i think it's a really interesting topic.. bear with me as i'm not highly experienced with docker but i think i grasp the principal — here's some of my thinking about it
for those who are not using docker
|
reading up on #26 some more, i'm seeing that the conversation about mounting the config directory is probably a more proper way to bring configuration into the it's kind of looking like #26 is great, and does most of what we're talking about already |
Hey @chase-moskal I finally pushed dockerized examples: https://github.com/nmaro/ooth/tree/master/examples/standalone For now there are no published standard images (the builds are all local), but it's a start. To a certain degree it could be argued that a standard |
The current next.js solution uses ooth, api and next.js server all in one. This means that only one cookie-session is needed. But if ooth and api are separate, 3 cookie-sessions are needed, + the server needs to be able to communicate with ooth and api (on the server side probably JWTs are better). Both ooth and the next.js implementation need to be extended to support that.
The text was updated successfully, but these errors were encountered: