Home page › Forums › Technical Support, Bugs and Fixes › API SSL support & Device Group permission scoping issues
Tagged: API SSL & Permissions
- This topic has 4 replies, 2 voices, and was last updated 4 hours, 5 minutes ago by
Hugo RIANT.
- AuthorPosts
- June 4, 2026 at 3:04 pm #8854
Hello,
I am currently deploying MikroWizard to manage a fleet of MikroTik devices and have two blocking points I need clarification on.
**1. API SSL (port 8729) support**
I could not find any option in MikroWizard to configure the connection to MikroTik devices over the API SSL port (8729) instead of the plain API port (8728). Is this supported? If so, how should it be configured? If not, is it on the roadmap?**2. Device Group permission scoping**
When restricting a user to a specific Device Group via Device Access Control, the dashboard and Device Logs still display data from all devices across the entire fleet — not just the ones belonging to the assigned group. This makes proper multi-tenant or role-based access control unusable in its current state.Is this a known issue? Is there a workaround or a fix planned?
Best regards,
Hugo1 user thanked author for this post.
- June 8, 2026 at 10:21 am #8856
Hi Hugo,
Thank you for your patience, and welcome to MikroWizard.
Regarding your questions:
1. API SSL (Port 8729) Support
At the moment, MikroWizard primarily uses the standard API port (8728). API SSL support (port 8729) is possible with a small code modification, but it is not yet exposed through the UI. This feature is already on the roadmap and is planned for an upcoming release, where it will be configurable directly from the MikroWizard interface.2. Device Group Permission Scoping
Yes, I am aware of this limitation. Currently, restricting users through Device Access Control does not fully scope all dashboard widgets and log views to the assigned Device Groups. Proper role-based and multi-tenant visibility controls are already planned and will be addressed in a future update.The next major release includes several significant improvements and new features. As MikroWizard is currently developed and maintained by a single person, development priorities are sometimes influenced by customer requirements, support requests, and other ongoing projects. This can occasionally affect the pace at which new features are delivered, but this area is definitely on my development roadmap.
If API SSL support is a blocker for your deployment, let me know more about your environment and requirements. I may be able to suggest a temporary workaround until the native UI option is available.
- June 9, 2026 at 7:32 am #8857This reply has been marked as private.
1 user thanked author for this post.
- June 10, 2026 at 10:08 am #8858
Hi Hugo,
Thank you for the additional details. Your use case is very helpful, and it aligns closely with features already planned for MikroWizard.
Regarding multi-tenant deployments, MikroWizard is planning to include a Customer Portal designed for end customers to access and manage only their own devices and services. This is intended to support exactly the kind of ISP deployment you described and is planned as part of the Pro version roadmap.
For the Device Group permission scoping issue, I completely agree that proper customer isolation is essential. Based on your feedback, I will prioritize the dashboard and log visibility changes so that user permissions are enforced consistently across the platform. My goal is to include these improvements in the next update. i can also help you to change needed parts of the code to use SSL with API.
Regarding API SSL (8729), I agree that encrypted management traffic should be the standard when devices are accessible over the public internet. I will also prioritize native API SSL support and make it configurable directly from the UI in an upcoming release.
As a temporary alternative, the Pro version already includes WireGuard management features. This allows you to build a dedicated management network between MikroWizard and your MikroTik devices, keeping API access on private WireGuard tunnels instead of exposing management ports to the public internet. For many deployments, this provides an even more secure management architecture.
Thank you again for the detailed feedback. Real-world ISP requirements like yours help shape the MikroWizard roadmap and priorities.
Best regards,
-
This reply was modified 6 hours, 13 minutes ago by
Sepehr.
-
This reply was modified 6 hours, 13 minutes ago by
- June 10, 2026 at 12:18 pm #8860
Hi Sepehr,
Thank you for the detailed response and for prioritizing both the permission scoping fix and the native API SSL support. That’s great news.
Regarding the API SSL patch, I actually already found a working solution while exploring the code. Here is what I modified:
1. /app/py/libs/util.py
Added ‘import ssl’ at the top, then updated the build_api_options function to use port 8729 with the following SSL options:
‘ssl’: True, ‘ssl_cafile’: None, ‘ssl_capath’: None, ‘ssl_verify’: False, ‘ssl_verify_hostname’: False, ‘ssl_force_no_certificate’: True, ‘hostname’: None2. /app/py/bgtasks.py
Same update applied to the two options dictionaries inside scan_with_ip which both had ‘ssl’: False hardcoded.This works correctly on our end with RouterOS v7 and no certificate on the MikroTik side.
Regarding the Customer Portal feature planned for the Pro version — this is very relevant to our use case. Could you clarify how it works exactly and what it covers? Also, given that we are currently in a POC phase with only a few devices, would it be possible to access the Pro features for a limited period (one or two months) to evaluate the Customer Portal before committing to a full deployment?
Best regards,
Hugo
- AuthorPosts
- You must be logged in to reply to this topic.