luci-app-olsr: migrate to JavaScript-based implementation

[Ayushmanwebdeveloper]

luci-app-olsrjs.mp4

Hi! I've almost completed the migration of luci-app-olsr to JavaScript. Most of the features are functioning just like they did in the old Lua app. There are only two minor bugs remaining in the status views, which I will make sure to fix soon.

You can review the changes and please provide any suggestions or improvements. Since this is a very large application, I believe there is ample scope for feedback.

During the migration, I implemented a new RPCD and made changes to how plugins and their configurations were handled in the old app. I have implemented plugin configuration using the previous approach used for interfaces.

Most of the work is complete and functional. I am also uploading a screencast for reference. Fixes #5363

Thank you for your time!

[Ayushmanwebdeveloper]

And one issue is the null that you can see in the screencast in some of the status views, which is actually the hostname that I'm attempting to obtain using hosthints.getHostnameByIPAddr(v.gateway). We're getting the data and hosthints successfully, as can be seen in the screenshot, but it's still returning null, meaning that the hostname not known
LuCI.network.Hosts.getHostnameByIPAddr

It's used in other apps & modules like this.

luci/modules/luci-mod-dashboard/htdocs/luci-static/resources/view/dashboard/include/30_wifi.js

Line 205 in fd5440a

name = hosthints.getHostnameByMACAddr(bss.mac);

But I'll attempt to fix it as soon as possible.

					network
						.getHostHints()
						.then(function (hosthints) {
							modifiedData = data.map(function (v) {
								if (resolveVal === '1') {
									var hostname = hosthints.getHostnameByIPAddr(v.gateway);

[jow-]

Looks good! You should deal with the empty hostnames by doing something like hostname || '?' when outputting them.

I see you do something like x = '<a href="http://' + v.hostname + '/blah">' + v.hostname + '</a>'; in various places. This will allow for XSS injections if someone broadcasts packets containing forged hostnames into the network. Ideally use LuCI's builtin format function together with the %h and %q placeholder which take care of HTML- and quote-escaping their arguments respectively:

x = '<a href="http://%q/blah">%h</a>'.format(v.hostname, v.hostname);

[Ayushmanwebdeveloper]

Looks good! You should deal with the empty hostnames by doing something like hostname || '?' when outputting them.

I see you do something like x = '<a href="http://' + v.hostname + '/blah">' + v.hostname + '</a>'; in various places. This will allow for XSS injections if someone broadcasts packets containing forged hostnames into the network. Ideally use LuCI's builtin format function together with the %h and %q placeholder which take care of HTML- and quote-escaping their arguments respectively:

x = '<a href="http://%q/blah">%h</a>'.format(v.hostname, v.hostname);

Okay! Sure, I'll fix it with the format function, and actually, in the old app, hostnames are visible instead of null. Means we've to find a way to get the hostnames. Because in my same VirtualBox OpenWrt, If I use the old Lua app, then all hostnames are visible.This is the only issue left.

[Ayushmanwebdeveloper]

Looks good! You should deal with the empty hostnames by doing something like hostname || '?' when outputting them.

I see you do something like x = '<a href="http://' + v.hostname + '/blah">' + v.hostname + '</a>'; in various places. This will allow for XSS injections if someone broadcasts packets containing forged hostnames into the network. Ideally use LuCI's builtin format function together with the %h and %q placeholder which take care of HTML- and quote-escaping their arguments respectively:

x = '<a href="http://%q/blah">%h</a>'.format(v.hostname, v.hostname);

I fixed that for every instance of the hostname.

[Ayushmanwebdeveloper]

Hi! @jow- @aparcar @feckert Now it's ready for review; I fixed all of the bugs, including the Hostname. Everything is functional, and we tested the package for the last 2 weeks and tried to resolve every issue. Could you please review? Thanks

[andibraeu]

@jow- @aparcar can you please take a look on that PR?

for me it looks good

[jow-]

@andibraeu - I don't have the means to runtime test but if you say it's fine then I'll go ahead and merge it. @Ayushmanwebdeveloper - thanks a lot for your effort!

[andibraeu]

@jow- is it possible to backport this app to 23.05? I just tested 23.05 and the old app doesn't work anymore there. The new one is working fine

[thuehn]

Hi all,

Just flashing our Freifunk Evernet last nigth with current OpenWrt trunk and Luci we run into the following issue, that might belong to this commit:

after flashing trunk, the LUCI webinterface did only show olsr status - no menu for admin/network & co anymore:

After deinstalling luci-app-olsr the Luci webinterface went back to a normal menu:

@andibraeu @jow- any hints from the experts ? (seems like something is overloaded by luci-app-olsr)

Greets Bluse

[Ayushmanwebdeveloper]

Hi all,

Just flashing our Freifunk Evernet last nigth with current OpenWrt trunk and Luci we run into the following issue, that might belong to this commit:

after flashing trunk, the LUCI webinterface did only show olsr status - no menu for admin/network & co anymore:

After deinstalling luci-app-olsr the Luci webinterface went back to a normal menu: @andibraeu @jow- any hints from the experts ? (seems like something is overloaded by luci-app-olsr)

Greets Bluse

Hello! We migrated the app such that status views are exposed to the public, which means they can be accessed without authentication.

Particularly in your openwrt theme, you can return to admin by choosing Administration in the bottom right area of the page.

In the Freifunk or Material theme everything works okay as shown in my screencast.

[thuehn]

Hiho

The button OLSR | ADMINISTRATION is nether on theme material nor on bootstrap visible at the bottom right on our side:

There is no exit to the admin web interface available as long as luci-app-olsr is installed.. ?

Greetz Bluse