ui navigation issues using container behind nginx reverse proxy in subfolder

Hello :)

I'm using CP in a docker container, in combination with swag (https://github.com/linuxserver/docker-swag/) for reverse proxy and cert management, and organizr (https://github.com/causefx/Organizr) for authentication and services aggregation. My goal is to have copyparty located folder of my main domain example.com/files/, but I'm having trouble setting it correctly. I'm using option rp-loc: /files in CP config, along with options xff-src: lan to whitelist rproxy traffic and idp-h-usr: X-WEBAUTH-USER for organir login. Swag uses nginx for reverse proxy, this is the config:

location /files {
    return 301 $scheme://$host/files/;
}

location ^~ /files/ {

    include /config/nginx/proxy-confs/organizr-auth.subfolder.conf;
    auth_request /auth-0;

    auth_request_set $auth_user $upstream_http_x_organizr_user;
    proxy_set_header X-WEBAUTH-USER $auth_user;
    proxy_set_header Connection "Keep-Alive";

    include /config/nginx/proxy.conf;
    include /config/nginx/resolver.conf;
    set $upstream_app copyparty;
    set $upstream_port 3923;
    set $upstream_proto http;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port;

}

For what I tried so far, most of the things work correctly, including file uploads using up2k and rproxy authentication. What breaks is navpane navigation: assuming my root is /files, if I define a volume like this in config:

[/admin]
  /data
  accs:
    r: *
    rwmda: admin

where /data is the root of my docker volume that has a subfolder sharex, and I define a second volume like:

[/admin/sharex]
  /data/sharex
  accs:
    wG: *
    rwmd: admin
  flags:
    e2d, d2t, fk: 4

In navpanel are created the following structure:

[root] -> url: example.com
  files -> url: example.com/files/
    admin -> url: example.com/files/admin/
      sharex -> url: example.com/files/admin/sharex/

With the control/admin panel located on example.com/files/.

I don't know if this is the intended behavior, but when setting the rp-loc setting, based on my config, I would expect to have the following structure instead:

[root] -> url: example.com/files/
  admin -> url: example.com/files/admin/
    sharex -> url: example.com/files/admin/sharex/

I also found a couple of bugs in the ui probably related to this configuration:

When creating a subfolder, two get request are triggered: one with ?tree= and one with ?ls= using the path of the newly created folder, but they are missing the prefix configured in rp-loc so they return 404. For example I go to the folder example.com/files/admin/music/ and I mkdir subfolder, the POST request returns 200, but the following get requests to the paths example.com/admin/music/subfolder/?tree= and /admin/music/subfolder/?ls= return 404. This breaks the interface, not showing the new dir and showing the rotating tree emojis animation until I refresh page or manage to change dir. The dir is created correctly server side.

cpbug

In navpane, after a fresh page load, when expanding and/or collapsing any folder using the "+" or "-" button to the left of it, the following ?tree= call returns a json with this structure: {"kfiles": {"a": ["subfolder"]}, "a": []} but in the interface the listing of that directory is shown as a child of an inexisting "files" directory. For example in my /admin/music/ I have 3 subdirs, if I expand the /admin/music/ dir from the interface, the ?tree= call returns {"kfiles": {"a": ["delete", "flac", "subfolder"]}, "a": []} but the interface shows:

subdir_expand

It generates a parent "files" directory, breaking navpane navigation, since that dir does not exist on the server.

As you stated in the docs, CP is not supposed to be run on a webserver subfolder, but I hope you'll consider looking into these issues so I can start using it as subfolder, and submit the swag config for other users to enjoy :)

In any case, I must congratulate to you for this amazing piece of software, and I'm really looking forward the ux redesign :)

sorry for wall of text

copyparty version

v1.13.8

Client details

OS version: ubuntu 20
browser version: firefox 128

thanks for the heads-up! i'll take a proper look when I'm home, but was at least able to reproduce the mkdir issue with my own setup, so I'll try to have it fixed by next ver -- probably on Sunday 👍

not supposed to be run on a webserver subfolder

well, it's moreso that it's not a very popular configuration, so it doesn't get a lot of testing -- but it is supposed to work :>

and submit the swag config for other users to enjoy :)

oh sick, thanks in advance 😁👍

really looking forward the ux redesign

uhh about that... i don't think anyones working on that , and it'll have to be someone other than me, since, well... look at the current one xD

many thanks, at the moment with this setup navigation is really an headache.. if you need the docker compose or other info to debug, let me know.

Forgot to mention, the image I'm using is copyparty/ac:latest.

Another small ui bug I noticed using firefox 128: in the configuration options panel, the "g" toggle on the left of the "dotfiles" seems to have a character that is not rendered correctly, it shows a rectangle with letters 2BAF: g⮯

guibug_ff128

I also tried with Brave 1.68.141 (in snap pkg) the square is not shown, but looks like there a space characater instead

guibug_brave

could there be that I'm missing something at the OS/browser level? can't try on windows at the moment..

As for the ux, in docs/devnotes.md is mentioned in future plans. Like it is right now is fine, I love theme 6, hate the bread emoji, I'd rather have cheese 🧀.. But I would really rethink the controls in top toolbar (including the emoji), when you get used to them is ok, but could be unintuitive for new users. The navigation elements are ok, when they work :) The control-panel prev/up/next links at bottom of page should be moved elsewhere imo.

In any case, I could work on a proposal mockup for an ui that respects functionality of the current one, maybe it could be implemented simply as a new theme.

alright, think I've got it fixed -- if you pull copyparty/ac:beta you should get something that works a bit better :>

I'll delete that tag once the release is out.

I don't know if this is the intended behavior, but when setting the rp-loc setting, based on my config, I would expect to [not see the rp-loc in the tree]

yup, this is (unfortunately?) intended -- stripping out those paths from the treeview would have made the js trickier, so I just left it in :p

think of it as a shortcut to the rest of the server? hehe

the "g" toggle on the left of the "dotfiles" seems to have a character that is not rendered correctly

yeah, I think you're missing a font with the more recent unicode additions, since that character is a fairly recent unicode addition -- it's a curved arrow pointing downwards. One good reason to throw out the emojis and instead use something like fontawesome for actual icons huh...

docs/devnotes.md mentions the ux rewrite in future plans

yup, you are absolutely right -- that one's on me! gotta rephrase the "future plans" section a bit to indicate that it's more of a list of dreams than things that will probably happen :grin:

as for the UI, I very much admit I'm not a ux wizard, but most of the decisions at least have some sort of reason behind them :>

I'm not a fan of burgermenus and having to click/tap more than necessary to get something done, so I'm fitting way too much into one screen I suppose :sweat_smile: so the top navbar is made to fit devices down to iphone5 or so, and shrinks dynamically if necessary. Of course, on desktops this is far less necessary, and using something more descriptive would probably be better. Or maybe the toolbar is the wrong way to go about it entirely...

The control-panel and prev/up/next links ended up at the bottom because my most common usecase was scrolling to the bottom of a folder, being like "now what", and felt like a "prev/next" down there would be nice. And I'll be honest, I had NO IDEA where else to put that control-panel link :p

and the "🍞..." is, of course, because it switches the navigation to "breadcrumbs"! tehepero

I would absolutely appreciate some fresh takes on the layout, and mockups especially would be awesome -- I'm expecting we'll have a good number of iterations on it, so something physical helps a lot. But I should warn you that I might have problems bringing up motivation to change something that works well for myself, so please be patient. Like, I'm only getting around to fixing issue 84 like this weekend :sweat_smile:

one final thing though, since I haven't mentioned it in the devnotes, is that modern webdev kinda... terrifies me to be honest :-P hundreds of dependencies to chase for updates, and tooling changing left and right. So that's why everything is plain organic js/css/html, and it would be awesome if we managed to keep it lean like that. Oh and I kinda don't wanna break support for old browsers either. So if someone who actually knows webdev wants to go crazy and build something way better, then I wouldn't have any issues just bundling up and shipping both frontends :>

EDIT2: just saw the flac filenames... great, now shikanoko is looping in my head again xD

I also forgot to mention, my "server" is on arm64/v8 platform, on beta tag I see only actual server arch :) No problem, I can wait for next release.

yup, this is (unfortunately?) intended

well, who am I to argue whether it's a bug or a feature, with the project creator nonetheless. I just noticed now, even the root node has a collapse toggle like the other nodes, only it is not visible, and activating it with $('#treeul > li:nth-child(1) > a:nth-child(1)').click() breaks the navigation, touché. I'll try to conjure up some custom css to hide them.

list of dreams than things that will probably happen

It's not to bad right now, so it makes sense it would be very low priority, if not any priority at all. Is one of the things you'd work on if you have inspiration or a good idea, so no pressure :)

For the UI on the other hand, if it were up to me, I'd change the position/icon of some controls, without modifying the overall layout. To accommodate any user, ui could by divided in sections so that users could configure every section with the controls they plan to use. Kind of like entering toolbar customization mode in firefox, where you have a set of toggles/actions/shortcuts buttons to place at your linking, the rest go into an overflow menu (definitely not an hamburger) where are accessible after one more click. Even if this was just a yaml config file applied on start/reload, not necessarily a live editing of the interface. If implemented well, could unlock ultimate flexibility.

Do you think a similar feature could be beneficial for CP?

The prev/up/next links as they are now make sense in mobile, but not in desktop imo. Maybe visibility could be toggled on or off in the settings. The control-panel link could be an new icon to the left of the cog emoji of the submenu.

I absolutely agree with you on having everything plain js/css/html and support for old browsers, and is actually one of the reasons why I really like CP!

eheh you deer

hi, I tested the new release and subfolder ls now works correctly, many thanks :) I ended up using this css to hide the elements I don't plan to use:

#wfp, #repl, #treeul > li:nth-child(1) > a:nth-child(2),
#ops > a:nth-child(1),
#ops > a[href="#v=bup"],
#ops > a[href="#v=msg"],
#ops > a[href="#v=player"],
#path > i:nth-child(2),
#path > a[href="/"] {
    display: none;
}

#ops {
    text-align: center;
    font-size: x-large;
    margin-top: 1.5em !important;
}

Would it be possible to add the id property to the a children of div <div id="ops">, so they have direct reference?

thank you!

tested the new release and subfolder ls now works correctly

awesome, glad to hear o/

and that looks like a solid enough solution, don't think it'll break anytime soon, good job 👍

Would it be possible to add the id property to toolbar tabs?

eh, i suppose #opa_bup looks a bit better than #ops > a[data-dest="bup"] for instance, but is there an actual benefit, like performance or whatever? or would that also make it easier to do more extensive hacking? just asking :>

Do you think [ui customization] could be beneficial?

my immediate response is "yes absolutely", but then i start thinking about the consequences... at the very least, would probably have to start doing automated ui testing at that point, to make sure that stuff doesn't randomly break when fixing other stuff.

I'll admit that there's a... manageable? amount of spaghetti relationships between the UI elements currently, so if you start moving them around then you'd probably get some nice surprises in return sooner or later. But it could also be a motivator to do some cleanup here and there.

So to summarize.... I'm not sure! w

The control-panel link could be an new icon to the left of the cog emoji of the submenu.

this is a good one -- I'm thinking that could be controlled by a css media rule to pop it up there if there's enough space 👍 and I'll try to think about the prev/next buttons too

oh and I'll close this since the actual issue is fixed, but feel free to keep the discussion going o/

I don't have any element with id #opa_bup in the page, there is a #op_bup which is the div that contains the form with upload input. For what I can see, all the children of #ops have this format: <a href="#v=bup" data-perm="write" data-dest="bup" tt="bup: basic uploader, even supports netscape 4.0">[emoji]</a>

My goal for the moment is just to hide some of these buttons, I'm just not very fond of them. No fancy hacking, I'm not qualified unfortunately..

Considering the corresponding divs have an id as they are unique elements in the page, I figured these could have one as well. I don't think there would be a measurable performance improvement, I'd just have less complex and more reliable rules in the custom css :)

[ui customization]

Another point to this argument could be; since many (most?) of the toggles already present in the web interface are there to provide the user the ability to customize the ui to their liking, it could be nice to expand and improve this feature.

I haven't checked, but there may already be out there a library that aims to provide such functionality in some form. Of course the goal remains to keep everything as lightweight and simple as possible, so it could be harder to find a suitable candidate. But maybe something, even just as source for inspiration, already exists..

I'm thinking that could be controlled by a css media rule to pop it up there if there's enough space

this, or could also be moved inside the expanded #op_cfg panel, so is always there, regardless of screen size.

9001 / copyparty

ui navigation issues using container behind nginx reverse proxy in subfolder #93