Join the conversation

Wekan

General

Wekan is an open-source kanban board (Trello like) which allows a card-based task and to-do management.

More active conversations

Wekan / General

Ports addresses for web vs api access

Wekan/General · January 3, 2020 at 8:31pm

Ports addresses for web vs api access

Wekan / General · January 3, 2020 at 8:31pm

I want to Thank Lauri again for yesterdays marathon Q&A session, most appreciated..... Here is my next challenge or confusion.....

When you set up wekan it needs to know a url as a root web entity. The entity could be arbitrary or could be a subdomain we aready own. Is that correct?That entity can have a port address. Whether I use one of three three methods of ssl or non-ssl proxy or just use an aws load balancer with ssl certificate, I get an address redirect from the outside world to the server serving the graphics of the wekan kanban board. Confirming those are correct assumptions.

Is the api I will use internally from another server on the same VPC not exposed to the outside world using the same port address? Should it? Is there a way to make it use a different port address so I do not have to expose the api to the outside world? If so what is best practice here?

Again the use case is that wekan provides a login to the outside world and the permission of that user login determines what they see and what they can do with what they see per swimlane, board, card, list etc. Those users and cards are populated by the api privately. The user interacts with wekan and the program populating through the api can monitor through the api any responses. The users of the populating app are a different group of users than the users accessing wekan directly through the web interface.

Please lmk if I am thinking about this completely wrong or assuming controls not in place or am worrying about security that is not an issue. If the api is the same port address as the web interface I assume the authentication token would protect or separate one from the other. Am I on the right track? If not, do I, can I should I set the api to a different port address and block that access at the VPC level?

Sorry for the book. Thank you again for a great program and even better answers :)

Load previous messages

January 3, 2020 at 9:25pm

Lauri Ojansivu@xet7

Team

9:25pm

otherwise Snap update to different version than Docker could mess up something

9:26pm

Maybe only one snap and some URL limiting webserver at front would be better

9:26pm

but I don't think having ELB in front of Wekan is good idea. Wekan requires websockets to work, and I don't know does ELB support websockets.

9:27pm

If there is websockets errors, you will see them in browser inspect console

9:32pm

Wekan does have bruteforce password guessing protections with accounts-lockout, there is snap settings for that, how many quesses are possible before blocking. Wekan also has XSS protection in web forms, and users that are not logged in can not change anything in database. Some permissions checks are serverside and some browserside, I have not tried yet is there a way to work around them in some way.

9:35pm

There is old hall of fame page for old security issues https://wekan.github.io/hall-of-fame/ although now that I look at it, there is old info. Wekan currently uses another accounts-lockout package and there is already settings for it.

9:36pm

I'm not currently aware of any existing security issues in Wekan. There is security page here https://github.com/wekan/wekan/blob/master/SECURITY.md

9:37pm

AFAIK old security issues have already been fixed

9:37pm

And Wekan dependencies are up-to-date in newest possible versions

9:41pm

BTW, did you listen to this episode of Security Now https://twit.tv/shows/security-now/episodes/746?autostart=false it has Show Notes here https://www.grc.com/sn/sn-746-notes.pdf it has info that it's possible for Open Source projects to ask Google to sponsor security fixes, there is link at PDF where to apply

9:41pm

I did ask, but it depends what they reply

January 3, 2020 at 11:21pm

Paul Verdone@pvcon13

11:21pm

Wow! That is a lot of great information. Thank you again. Here is some minor replies. AWS ELB (old style) can be made to pass websockets I believe by overloading input with TCP and http. Alternatively the application load balancer is supposed to be designed to pass websockets (no have not tried that as yet). I guess I will protect the api port addresses with whatever is in front of the wekan server be it proxy or elb, etc, and make the authentication system earn its keep. The most interesting part of your answers above is about granularity of access on objects exposed (cards and lists) by login. You listed out several reasons for, and methodologies (worker vs organization-teams), to provide limited access to exposed objects by authentication. Sounds like you are on track to get that done sometime soon. Kudos on that for you:). When I get past what I am doing, perhaps can see what exactly you are working on and if I can help, do some pull requesting on those subjects ,if the code is something I can get my head wrapped around. Otherwise what I might have to do in the mean time is register all my users of wekan through my app and let my auth system gateway to specific entities in wekan, (this card ok, this card not ok for this user. Really not sure if that is even doable versus easy. In a week I should be closer to knowing that. Thank you again sir :) All the best and Happy new Year.

Lauri Ojansivu@xet7

Team

12:11am

Thanks! All the best and Happy New Year to you too :)

January 8, 2020 at 9:08pm

Lauri Ojansivu@xet7

Team

9:08pm

About those roles, I already added Worker role, same way I did add previous roles. I did not add granular permission system this time, that would mostly have required a lot more work. There is related issue here about how it was done, and read only role https://github.com/wekan/wekan/issues/2876

January 11, 2020 at 1:40am

Paul Verdone@pvcon13

1:40am

Thank you :)