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 :)

January 3, 2020 at 9:08pm

Lauri Ojansivu@xet7

Team

9:08pm

One way is to disable API with sudo snap set wekan with-api='false' , and then monitor all of Wekan with Admin Panel Global Webhook

9:09pm

When API is disabled, users can not export board, and can not access user or admin API at all

9:10pm

You can also start another copy of wekan-app with docker that users same mongodb database at port 27019 with different settings

9:10pm

Or alternatively, have some webserver in front of Wekan that blocks API URLs

9:11pm

and only allows API calls from specific IP address

9:12pm

9:13pm

If doing it with only Docker

9:15pm

If you have Snap already, you can start additional wekan-app Docker-container without database, using settings at command line like this, with just Docker commands https://github.com/wekan/wekan/wiki/Docker

9:17pm

When currently coding that Worker role, I have been thinking should I add more granular role permissions, so it would be possible at Admin Panel define new roles, and specify can user with that role open cards, comment to cards, see what menu options, etc

9:18pm

Because otherwise I would need to code all different kind of roles myself to Wekan code

9:19pm

That permission system would probably be also needed with Organizations/Teams feature I'm developing

9:19pm

For example, which role has access to which Organization(s) or Team(s)

9:21pm

Or alternatively, I could try to fix current nearly-ready Worker role.

9:25pm

Hmm, I don't think is it a good idea to run snap+docker at the same time. It should be 2 snap or 2 docker.

9:25pm

If really 2 wekan installs would be required

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

Join the conversation

Wekan

More active conversations

Ports addresses for web vs api access

Ports addresses for web vs api access

Paul Verdone

Ports addresses for web vs api access