4 ms·

Show HN: Dashboard – self-hosted accounts, orgs and subscriptions for web apps

78 points by benologist 7y ago

jitl 7y ago
Why did you name this “Dashboard”? Very confusing since “dashboard” is such a generic and well-used term in software engineering.
- leetbulb 7y ago
  While I agree, I also kind of like it. Aside from that, the project looks really awesome. Great job!
- darekkay 7y ago
  I'm also working on a project called "Dashboard" [1]. But I agree - while the name fits perfectly, it's way to generic to find it anywhere. [1] https://github.com/darekkay/dashboard https://github.com/darekkay/dashboard
jmoore53 7y ago
Project looks awesome, but I was a little confused. Is this a centralized user management with payments proxy to many application backends? https://userdashboard.github.io/home https://userdashboard.github.io/home The home page did a really good job explaining with images, but wanted to confirm.
- deleted 7y ago
  [deleted]
- benologist 7y ago
  You host a uniquely-configured copy of Dashboard for each web application. It only requires some small changes I can investigate tomorrow that would let you use one copy for multiple applications.
- benologist 7y ago
  This is implemented now, you can add a "before" request handler [1] and inspect the HOST header to check the domain and switch to an alternative configuration for that request. Dashboard compiles a global.packageJSON [2] holding your template, title, menu links etc and you can override that per-request by setting an alternative req.packageJSON for more individualized site settings too. Each of your application servers can serve a '/public/template-additional.css' and '/public/content-additional.css' to override the appearance as well. module.exports = { before: async (req) => { switch (req.host) { case 'domain1.com': req.dashboardServer = 'domain1.com' req.applicationServer = 'http://localhost:7000' req.applicationServerToken = 'shared secret' break } } } This will work with per-site user accounts because the data was already partitioned by the dashboard server address. I think for sharing accounts across multiple websites you could just omit changing the req.dashboardServer. [1] https://userdashboard.github.io/request-handlers https://userdashboard.github.io/request-handlers [2] https://userdashboard.github.io/package-json https://userdashboard.github.io/package-json
CGamesPlay 7y ago
This is pretty interesting. Is there any prior art for things like this? User management that integrates with a specific target application, I mean, rather than say a generic SSO solution.
- benologist 7y ago
  There is similar stuff for games and mobile apps but you're usually left implementing your own UI in whatever technology on top of a REST API. https://xsolla.com https://xsolla.com Another analogy is Facebook some years ago when Farmville and Zynga were incredibly popular. Facebook had this platform for apps where you wrote "FBML" which was a secured subset of HTML they would translate and then put into a frame on their website where people would use your app or game. If you were writing an app in that era you would fetch user information from their API etc. HTML has changed enough to skip an intermediate FBML language today. Drupal and WordPress are also quite similar the main difference is your content, your application, resides on a second server instead of combined which is how Dashboard is stack-agnostic.

78 points by benologist 7y ago

jitl 7y ago

Why did you name this “Dashboard”? Very confusing since “dashboard” is such a generic and well-used term in software engineering.

leetbulb 7y ago
While I agree, I also kind of like it. Aside from that, the project looks really awesome. Great job!
darekkay 7y ago
I'm also working on a project called "Dashboard" [1]. But I agree - while the name fits perfectly, it's way to generic to find it anywhere. [1] https://github.com/darekkay/dashboard https://github.com/darekkay/dashboard

jmoore53 7y ago

Project looks awesome, but I was a little confused. Is this a centralized user management with payments proxy to many application backends? https://userdashboard.github.io/home https://userdashboard.github.io/home The home page did a really good job explaining with images, but wanted to confirm.

deleted 7y ago
[deleted]
benologist 7y ago
You host a uniquely-configured copy of Dashboard for each web application. It only requires some small changes I can investigate tomorrow that would let you use one copy for multiple applications.
benologist 7y ago
This is implemented now, you can add a "before" request handler [1] and inspect the HOST header to check the domain and switch to an alternative configuration for that request. Dashboard compiles a global.packageJSON [2] holding your template, title, menu links etc and you can override that per-request by setting an alternative req.packageJSON for more individualized site settings too. Each of your application servers can serve a '/public/template-additional.css' and '/public/content-additional.css' to override the appearance as well. module.exports = { before: async (req) => { switch (req.host) { case 'domain1.com': req.dashboardServer = 'domain1.com' req.applicationServer = 'http://localhost:7000' req.applicationServerToken = 'shared secret' break } } } This will work with per-site user accounts because the data was already partitioned by the dashboard server address. I think for sharing accounts across multiple websites you could just omit changing the req.dashboardServer. [1] https://userdashboard.github.io/request-handlers https://userdashboard.github.io/request-handlers [2] https://userdashboard.github.io/package-json https://userdashboard.github.io/package-json

CGamesPlay 7y ago

This is pretty interesting. Is there any prior art for things like this? User management that integrates with a specific target application, I mean, rather than say a generic SSO solution.

benologist 7y ago
There is similar stuff for games and mobile apps but you're usually left implementing your own UI in whatever technology on top of a REST API. https://xsolla.com https://xsolla.com Another analogy is Facebook some years ago when Farmville and Zynga were incredibly popular. Facebook had this platform for apps where you wrote "FBML" which was a secured subset of HTML they would translate and then put into a frame on their website where people would use your app or game. If you were writing an app in that era you would fetch user information from their API etc. HTML has changed enough to skip an intermediate FBML language today. Drupal and WordPress are also quite similar the main difference is your content, your application, resides on a second server instead of combined which is how Dashboard is stack-agnostic.