Hi
Been playing with branding Package and in 2-3 days of coding made this. 
This thsould allow to give your end-user a simple interface to see or maybe even change stuff in much easeir way.
What you think ?
https://tikview.net/
Looks better than recent WebFig.
Great work.
I have long want CORS support to enable developing SPAs like this one. I guess using a Branding package gets around that restriction (at the expense that these are not removable and upgrade requires installing a new branding package I suppose).
Did you publish the source code anywhere? Are you using the REST API, or are you using undocumented jsproxy.js from newer webfig?
(moved down)
Something like this and open source would help a lot for my "less technical" customers.
Currently, just using skins with limited options.
Nice, 404...
https://<NO INDEX>.net/download/dpk
Until //someone// check and approve it, I recommend ANYONE(*) to not install anything.
The .dpk could contain any script that does anything, literally.
It's not just a simple interface to look at and play with.
(*) except who already know how to ckeck
Can be one hacked account, last post is from 2020...
Also nice the empty TikViewReactDashboard.dpk at 0 byte...
Thanks for the feedback everyone! 
@rextended - You're absolutely right to be cautious - trust but verify is the way!
Though I promise my DPK doesn't mine crypto or install a backdoor to order pizza
on your router 
But seriously, your security concerns are valid. The DPK contains only HTML/JS/CSS
files for the dashboard UI - no scripts, no system modifications, just a pretty
face for the REST API.
To address the trust issue: I'm making the code open source!
GitHub: GitHub - cieplik206/tikview
You can review every line before installing.
Fixed the download link (my bad!): https://tikview.net/download/dpk
@Amm0 - Using REST API exclusively. The branding package approach is actually
pretty clever for avoiding CORS issues.
@itimo01 - This is exactly why I built it - for less technical users who don't
need the full WebFig complexity.
The basic version will always be free and open source. Planning some Pro features
for advanced monitoring, but the core dashboard stays free.
PS: @rextended - After you review it, would love your feedback! Your paranoia
might catch something I missed 
When is more than 0 byte...
Try again push is now completed to web
Yes, I'm paranoid, I know, but in Tuscany (Italy) they say, "Better to be afraid than to be hurt..." IT:"Meglio aver paura che buscarne"
Which for me is better than the English version...
"Better safe than sorry"
FWIW, you can use GitHub actions to build it. I can provide a pull request to build it on GitHub if you're interested.
_____ _ _ __ ___
|_ _(_) |/ / | \ ___
| | | | < | |) |/ _ \
| | | | |\ \ | _// (_) |
|_| |_|_| \_\ |_| \___/
React Dashboard v1.0
I don't see the need to change the device name. Replacing MikroTik everywhere with TikViewReactDashboard.
Why change the logo in the terminal?
Why replace defconf-caps, which happens to be part of the initialization scripts...
I don't see the point of initializing HIDE_DEFCONF_PROMPT as if loading your own default script.
Index.js is obfuscated enough to not be evaluated in a few moments.
It requires some study, which can't be done in two minutes.
Obviously, if compiled the sources and get the same file again, no problem.
These are the side-effects of having to use the branding kit to get HTML files added to router. What's annoying is that netinstall cannot copy the same files. And since you cannot run this code on another server since you'd run in CORS restrictions and need to use a "CORS proxy" (see Using Caddy Server as CORS Proxy for REST API for example).
So I can see how you're left with branding - which comes with the associated side-effects like needing to change defconf (or have a more complex install process to deal with scripting part separately).
Agree. I saw this in the docs too. In branding, this become the platform in discovery.
It's transpiled from TypeScript (using React libraries), so imagine it be very unreadable... OP has the source on GitHub, so you may better offer "compiling" it and creating the package yourself...
I'm concerned about security, not compiling.
If he later uploaded the code to GitHub, it's certainly still verifiable.
But since I don't know how to do it (let's call it "compiling"),
it's enough if users who create their own branding don't also upload the related "defconf" files...
However, anyone who downloads a .dpk file from ANYONE and doesn't know how to check its contents FIRST is
always at risk of man-in-the-middle if someone hack the site.
P.S.: I'm nobody, I don't see why someone should trust me if I provided the .dpk file...
Anyway, I think we should separate the good work that went the underlying React project - which is pretty slick/modern ... from the fact the only way create a SPA for RouterOS is seemingly via branding.
Now this doesn't change @rextended legit concerns about branding-as-app-packaging. Just branding kit is needed since netinstall cannot actually copy the needed files. MikroTik really should have option to netinstall to allow copying web content which avoid the need for the branding kit.
And as I note, you cannot just host the pages someplace else because you need CORS support from REST API – which it lacks. In a ticket about CORS, MikroTik said recently CORS was not near-term agenda, so I wouldn't wait for that.
@rextended - Fair points, all noted!
You're right about the device name and terminal logo - I was just playing around
with the automatic DPK builder and it populated all those fields. Got a bit
carried away testing what the branding package could do! 
Will definitely clean this up in the next version:
- Keep standard MikroTik branding/device names
- Remove the defconf-caps changes
- Remove HIDE_DEFCONF_PROMPT
- Only replace the webfig UI files
The JS is just bundled/minified by Vite (React build tool), not obfuscated.
Standard output when you bundle 100+ React files into one. You can verify by:
git clone GitHub - cieplik206/tikview
npm install && npm run build
Compare the output - it'll match what's in the DPK.
@Amm0 - Thanks for the GitHub Actions offer! However I already have a automated script for building DPK using playwright so I am fine, I personally dont need one,
About why DPK over external hosting:
The beauty of DPK isn't just solving CORS. When the dashboard is on the router
itself:
- Works offline - Access your router even when internet is down (which is
usually when you need it most!) - Survives factory reset - Branding packages persist through resets
- No external dependencies - Everything runs locally
- Faster - No external server latency
Hosting externally defeats the purpose - routers should be self-contained. You
go to the router UI when something's wrong, often when external connectivity is
the problem!
Appreciate all the feedback - this is exactly the discussion I need to make
this tool better and more trustworthy! 
@rextended - Your "paranoia" is healthy skepticism that keeps the community safe.
Keep it up!
Only to show how Tuscany can be different, I would have said : "Meglio aver paura che toccanne"
On the other hand "Non ha il palio se non chi corre" <- you cannot have a prize/reward unless you take part in the race.
@cieplik206
It looks good- 
You should (IMHO) add a command line snippet example in "Create API User" paragraph.
About this (I understand how it largely is a limitation of Mikrotik):
Removal Options: There are only two ways to clear TikView from your router:
- Create and install a new DPK package that will overwrite the previous one
- Perform a full netinstall procedure (complete router reinstallation)
It is IMHO very inconvenient for a new user willing to only test it.
Semi-random question:
Would it be possbile to create a .dpk that is EXACTLY the default Mikrotik one, so that one can call it "undotikview.dpk" and install that to return the device "as before"?
Yes, of course...
I've always avoided posting this because I don't want MikroTik to get pissed off at me for providing a quick way around vendor-imposed branding...
@jaclaz
Great feedback! Here's what I've implemented:
Command Line Examples Added
"Undo" DPK Package Created!
Excellent suggestion! I've already created exactly what you asked for:
undo-tikview.dpk (68KB)
- Contains ONLY standard MikroTik branding (default ASCII logo, URLs, etc.)
- No custom files uploaded
- Effectively returns the router to "factory default" WebFig
Also added support for switch Light / Dark mode
Files Available:
- Tikview-v0.2.dpk - Full TikView React dashboard with theme switcher
- undo-tikview.dpk - Restoration package to return to default WebFig
Both packages use standard MikroTik branding to maintain consistency with RouterOS.
Thanks for the valuable feedback - this makes the project much more user-friendly for testing! 