freyacodes
Web Dashboard
I plan on creating a web dashboard primarily for fiddling around with bot permissions in a similar manner to the Discord permission system:
The dashboard should have these features:
- Standard Discord permissions for the server, text channels and voice channels
- Additional bot permissions (play, stop, skip, NSFW, send commands, etc)
- Manage permission overrides
- OAuth2 login panel for authenticating with Discord
- Maybe a Patreon link system
- A simple list of servers
Further commands may follow, like kick ban and mute commands
My hope is that this major feature can be completed with the help of someone with experience on interactive websites. I will be able to provide an API to interface with, so the main concern is the front-end. Comment on this issue if you are interested.
That'd be great! The site is coded with React.js. Got any experience with that? Otherwise, it's not too difficult to learn.
The repo for the web project is located at https://github.com/Frederikam/FredBoat-Web
Master is automatically built to https://fredboat.com/
React is fairly easy to learn. Consider the fact that this is my first non-static website.
https://facebook.github.io/react/
On 24 January 2017 at 10:32, Alper Berber [email protected] wrote:
I don't have any experience with React.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Frederikam/FredBoat/issues/23#issuecomment-274753082, or mute the thread https://github.com/notifications/unsubscribe-auth/ACdoWcvlvCq-5HH3Wkl62qw6Cm-h1zWDks5rVcVBgaJpZM4KGdGT .
@Frederikam If you're still in need of this, I know a bit of React and UI/UX design. I would love to help out with this.
Hey there @celanthe. Yes, this is still on the table and I would love some help, though I'm still wondering about how I am going to build the API gateway.
Be sure to ask if you need more info.
@Frederikam I am wondering if https://github.com/celanthe/ReactJS-AdminLTE would be a good jumping off place to start for said dashboard?
Unsure as to the gateway!
The API gateway is backend territory so it's probably something I'll end up dealing with. It's just impossible to finish this issue without it.
That React based template looks really neat and could be a useful starting point if you choose to delve into that. We don't need to really worry about having user customizable widgets and things like that, though.
@Frederikam Fantastic! I'll delve into this over the next couple of weeks.
@Frederikam slow progress, but still some progress. ^_^ Curious as to how you want the server permissions handled? For the sake of missing the back-end piece, would the commands from Discord need to actually do anything at this point?
I am assuming that the permissions in question are those listed at: https://discordapp.com/developers/docs/topics/permissions#role-object
EG: If someone clicks on the 'Discord Permissions' page in the sidebar, from there would it be enough to list the permissions for now in a table/with icons or somesuch until the back end is figured out?
Looks like you're off to a good start!
Here's some quick feedback:
- We don't need to tell users that they are online. This is not a social platform.
- I don't plan for this dashboard to be able to handle Discord permissions. That would be tricky to implement and would require maintenance for each new Discord permission.
- Overrides are quite low priority at the moment, but if we do wind up getting them, we'll want to use the same layout as Discord rather than having a separate tab.
- Sync with Discord? Not sure what that is supposed to be. Do you mean account authentication? People will need to authenticate to even view the dashboard.
- The user must have some way of switching the server they are looking at managing.
I'm not sure what you are asking in regards to how we handle role permissions. In essence, we are just cloning Discord's UI for permissions, only with our own set of permissions. I'll need to think about exactly which permissions we want.
The base URL of the gateway will be https://fredboat.com/api/
I currently only intend to use the identity and identity.guilds scopes for oauth. The latter allows us to retrieve a list of guilds the user is in, and which permissions they have there.
@Frederikam Ohh I see. I was making this much harder than it has to be, for sure! Wonderful. I'll get back to this over the weekend, for sure. :) That makes this a lot simpler.
@Frederikam just wanted to update--should have some time to work on this next weekend for a bit. I work f/t so I'll progress through as time allows! Look forward to working on it.
Sounds good! There's no need to rush it though. I got my studies (and currently also exams!) to worry about, so getting around to doing the gateway will take some time.
On 14 March 2017 at 21:23, Kiran [email protected] wrote:
@Frederikam https://github.com/Frederikam just wanted to update--should have some time to work on this next weekend for a bit. I work f/t so I'll progress through as time allows! Look forward to working on it.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Frederikam/FredBoat/issues/23#issuecomment-286548021, or mute the thread https://github.com/notifications/unsubscribe-auth/ACdoWZCDtShMyHZKaqx1c91h-1iWyoOOks5rlvdagaJpZM4KGdGT .
There are quite a few problems here:
- [ ] The avatar is too big and there's no form of padding.
- [ ] You're mixing the guild selection with the guild settings. It's really odd to have it there, seeing from a UX design perspective.
- [ ] You're not using react-router for this page. The route should be something like
/guild/:guildId/manage. - [ ] Why is the home tab on the bottom? Most designers would put it at the top of the list.
- [ ] The home page is a mess. Why have those big unpadded banners when you can just style some simple buttons? We have an about page btw.
- [ ] Please use the same checkboxes that we use on the master branch. They are identical to what Discord uses.
It may be simpler to simply just fork master and continue my work. We already have react-router and checkmark components in place
@Frederikam Thanks for the feedback. I'll revisit this at a later date and follow your advice for forking the master repo.
So, because ASP.NET Core, I've made this: http://imgur.com/a/5f2x3 (Note this is for anonymous users, the main page cuts straight to the dash for logged in users)
I've almost done setting it up with Discord OAuth2. It runs on .NET Core (so multiplatform and performance gains ftw) Uses Semantic UI
@averagenamespace looks really great! I particularly like the first image.
The system I had in mind is where the front-end is located on a CDN (namely netlify) and where API calls are made to https://fredboat.com/api/some_route.
Though a big problem with this is that it splits the stack into .NET and Java. Not completely sure how that is going to work. @Nanabell told me he would like to help if only he did Java.
@Frederikam Has anything happened on the API end? I was assuming the API was going to be hosted separately (Java/whatever API backend communicates with ASP/React frontend), but if nothing has happened I can easily add some API controllers to this project, for example:
Which produces a result like this:
The [HttpGet] attribute can be changed to HttpPost, HttpDelete, HttpPut etc
I see an application stack like this:
(Or we skip the middle layer and connect the dash straight to the FredBoat client?)
Notes:
- Could seperate middle layer (Java)
- Could cut the second layer and connect the FredBoat client directly to the web dashboard
- At the moment the top and second layer are on the same application (FredBoatDashboard.sln, coming soon to a repository near you)
The problem with this is that FredBoat will eventually be dockerized into many different shards. My plan was for the API server to also manage those.
However, I'm not sure how your second layer fits in. By the third layer do you mean the bot itself?
Top layer: Front-end UI (logins, dashboard, etc...) Middle layer: ASP.NET API (sends data to FredBoat etc) Bottom layer: Existing FredBoat (FredBoat.jar, the actual bot that plays music and is awesome)
On Sun, 19 Mar 2017 at 12:23 PM, Frederik Ar. Mikkelsen < [email protected]> wrote:
The problem with this is that FredBoat will eventually be dockerized into many different shards. My plan was for the API server to also manage those.
However, I'm not sure how your second layer fits in. By the third layer do you mean the bot itself?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Frederikam/FredBoat/issues/23#issuecomment-287582327, or mute the thread https://github.com/notifications/unsubscribe-auth/AY3edJcWEPOVKmM1D_r74hF-47XKjW2Jks5rnGeAgaJpZM4KGdGT .
For now, I'll focus on building the web dashboard. Do you have a general idea of what the URLs are for the API endpoints? For the requirements you stated in the first post: ~~I don't get what you mean by the first one, do you mean like a role editor? I don't think I can do that with the Discord API.~~ If you mean roles like FredBoat-only roles (add a user to a role, user can only do X or cannot play music etc), then with appropriate API endpoints, yeah, I can. I can sort out updating what the bot can and cannot do from the dashboard, I just need a URL I can call (POST preferred) with a data object containing the new permissions (that I would assume update your local DB).
Progress:
Notes: Today was slow, because OAuth2 was hard to set up. Firstly, it wouldn't show up in ExternalProviderSchemes. Then it wouldn't connect. But it works now 👍 I'm going to start working on the main dashboard (I'll just use a temporary fake data internal API for now, until the details for the API are done/whatever) but if you need anything changed just say.
I'm going to open-source it, but for now it's going to be on GitLab (because private repositories) because there is still some sensitive data (Discord app login data, for testing at the moment).
Written in Visual Studio 2017 and tested in Google Chrome
It is not desirable to add password/email auth. This makes the dashboard needlessly complicated. It would mean that we would have to ensure that passwords are safely hashed when stored, etc. Not to mention that we would need to re-authenticate a user if they choose to revoke access: https://cloud.githubusercontent.com/assets/2582617/24081998/a28d9a4a-0cbe-11e7-87f5-3f0d50f9411e.png
A user should only have access to the dashboard if they have a valid bearer token stored in their browser.
Additionally, I don't feel like we are on the same page in regards to the stack. https://cloud.githubusercontent.com/assets/2582617/24081999/a676936e-0cbe-11e7-9ae3-cadac4924b3a.png
I plan to scale FredBoat with docker containers. At some point, we'll need a controller for these that can manage the shards (check if working properly, rolling restarts, etc). My initial thought was to make this the same program as the one serving API requests, but I don't see how that fits in with your .NET program. Ideas?
Yeah, I see what you're saying. I'll change it so that they are identified by OAuth2 bearer tokens.
If you can provide endpoints, I can roll a socket manager into the middle layer?
On Mon, 20 Mar 2017 at 4:10 AM, Frederik Ar. Mikkelsen < [email protected]> wrote:
It is not desirable to add password/email auth. This makes the dashboard needlessly complicated. It would mean that we would have to ensure that passwords are safely hashed when stored, etc. Not to mention that we would need to re-authenticate a user if they choose to revoke access: [image: Inline images 1]
A user should only have access to the dashboard if they have a valid bearer token stored in their browser.
Additionally, I don't feel like we are on the same page in regards to the stack. [image: Inline images 2] I plan to scale FredBoat with docker containers. At some point, we'll need a controller for these that can manage the shards (check if working properly, rolling restarts, etc). My initial thought was to make this the same program as the one serving API requests, but I don't see how that fits in with your .NET program. Ideas?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Frederikam/FredBoat/issues/23#issuecomment-287623020, or mute the thread https://github.com/notifications/unsubscribe-auth/AY3edEzjrbBsUiEn00baPsz2erCw2gdMks5rnUVQgaJpZM4KGdGT .
Socket manager? What do you mean by that?
On 19 March 2017 at 20:34, averagenamespace [email protected] wrote:
Yeah, I see what you're saying. I'll change it so that they are identified by OAuth2 bearer tokens.
If you can provide endpoints, I can roll a socket manager into the middle layer?
On Mon, 20 Mar 2017 at 4:10 AM, Frederik Ar. Mikkelsen < [email protected]> wrote:
It is not desirable to add password/email auth. This makes the dashboard needlessly complicated. It would mean that we would have to ensure that passwords are safely hashed when stored, etc. Not to mention that we would need to re-authenticate a user if they choose to revoke access: [image: Inline images 1]
A user should only have access to the dashboard if they have a valid bearer token stored in their browser.
Additionally, I don't feel like we are on the same page in regards to the stack. [image: Inline images 2] I plan to scale FredBoat with docker containers. At some point, we'll need a controller for these that can manage the shards (check if working properly, rolling restarts, etc). My initial thought was to make this the same program as the one serving API requests, but I don't see how that fits in with your .NET program. Ideas?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/Frederikam/FredBoat/issues/23#issuecomment-287623020 , or mute the thread <https://github.com/notifications/unsubscribe-auth/ AY3edEzjrbBsUiEn00baPsz2erCw2gdMks5rnUVQgaJpZM4KGdGT> .
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Frederikam/FredBoat/issues/23#issuecomment-287641003, or mute the thread https://github.com/notifications/unsubscribe-auth/ACdoWRpKPFni7-5EkK1ByeJgEb2lZIY8ks5rnYMwgaJpZM4KGdGT .
Failed at phone typing, I meant docker. On Mon, 20 Mar 2017 at 8:35 AM, Frederik Ar. Mikkelsen < [email protected]> wrote:
Socket manager? What do you mean by that?
On 19 March 2017 at 20:34, averagenamespace [email protected] wrote:
Yeah, I see what you're saying. I'll change it so that they are identified by OAuth2 bearer tokens.
If you can provide endpoints, I can roll a socket manager into the middle layer?
On Mon, 20 Mar 2017 at 4:10 AM, Frederik Ar. Mikkelsen < [email protected]> wrote:
It is not desirable to add password/email auth. This makes the dashboard needlessly complicated. It would mean that we would have to ensure that passwords are safely hashed when stored, etc. Not to mention that we would need to re-authenticate a user if they choose to revoke access: [image: Inline images 1]
A user should only have access to the dashboard if they have a valid bearer token stored in their browser.
Additionally, I don't feel like we are on the same page in regards to the stack. [image: Inline images 2] I plan to scale FredBoat with docker containers. At some point, we'll need a controller for these that can manage the shards (check if working properly, rolling restarts, etc). My initial thought was to make this the same program as the one serving API requests, but I don't see how that fits in with your .NET program. Ideas?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/Frederikam/FredBoat/issues/23#issuecomment-287623020 , or mute the thread <https://github.com/notifications/unsubscribe-auth/ AY3edEzjrbBsUiEn00baPsz2erCw2gdMks5rnUVQgaJpZM4KGdGT> .
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/Frederikam/FredBoat/issues/23#issuecomment-287641003 , or mute the thread < https://github.com/notifications/unsubscribe-auth/ACdoWRpKPFni7-5EkK1ByeJgEb2lZIY8ks5rnYMwgaJpZM4KGdGT
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Frederikam/FredBoat/issues/23#issuecomment-287641086, or mute the thread https://github.com/notifications/unsubscribe-auth/AY3edNfCo7GQ3FLwSRlYWvvqq-LImFlfks5rnYN4gaJpZM4KGdGT .
Sorry, but I fail to realize how that would work. API endpoints to control the swarm?
Endpoints for each docker so that I can ping it and receive an acknowledgement along with status details?
On Mon, 20 Mar 2017 at 8:39 AM, Frederik Ar. Mikkelsen < [email protected]> wrote:
Sorry, but I fail to realize how that would work. API endpoints to control the swarm?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Frederikam/FredBoat/issues/23#issuecomment-287641485, or mute the thread https://github.com/notifications/unsubscribe-auth/AY3edAByKgDSkc0R5ngPqPts6egEl_kWks5rnYSJgaJpZM4KGdGT .