Hello Daniel,

we changed the default layout already last year and the new router will not work without the /webui prefix. It should be easy to add redirect rules where needed or use reverse proxy / rewrite rule if there is a strong need to keep the old scheme, there are no plans to add a dynamic router to the core code. The the commented apache config is simply a leftover which we did not clean up - thanks for pointing. With one of the next updates we will also provide a nginx config and switch to it as a default, as header rewriting and reverse proxy setups are a lot easier with it.

best regards

Oliver


On 19.07.25 00:08, Daniel Hoffend wrote:
Hi

I've a question regarding the new webui application server and its url/service routing. With the old fcgi method the default url was (afaik) /openxpki/ when accessing a single-realm setup or /realm1/ and /realm2/ in a multi-realm setup with path as realm_mode.

The new application router doesn't seems to not provide these options.

Looking at the url routing, the only registered/declared route seems to to be /webui/realmname https://github.com/openxpki/openxpki/blob/master/core/server/OpenXPKI/Client/Service/WebUI.pm#L540

The default configuration suggest that using /openxpki/ should work in single realms. https://github.com/openxpki/openxpki-config/blob/develop/contrib/apache2-openxpki-site.conf#L139

But when I tried accessing the demo site, those urls are not working and always resulting in an 404 error when the page tries to load data from the server.
https://demo.openxpki.org/openxpki/ (as per docu)
--> The webserver did not return the expected data.
Possible causes: OpenXPKI client is not running; authentication session has expired; an internal error.
HTTP code: 404

Looking at the debug logs those are my registered routes
Routes: [pid=236730]
  /                                 *    ^ [pid=236730]
    +/healthcheck                   GET  ^\/healthcheck [pid=236730]
    +/healthcheck/<command>         GET ^\/healthcheck/([^/.]+) [pid=236730]
  /                                 *    ^ [pid=236730]
    +/rpc/<endpoint>/<method>       * ^\/rpc/([^/.]+)(?:/([^/.]+)?)? [pid=236730]
  /                                 *    ^ [pid=236730]
    +/scep/<endpoint>/<*throwaway>  * ^\/scep/([^/.]+)(?:/(.+)?)? [pid=236730]
  /                                 *    ^ [pid=236730]
    +/webui/<realm>                 *    ^\/webui/([^/.]+) [pid=236730]

It looks like the old way of accessing the webui realms are currently no longer available.

Just for fun, I've added a temp route to the Client/Service/WebUI.pm would make it work,

    $r->any('/<realm>')->to(
        service_class => __PACKAGE__,
        endpoint => 'default',
    );

But I guess that should be registered somehow as fallback route. Or we could add routes regarding to the route.map assignments. Without testing I guess that even when then the realm.mode set to hostname, the current webui would have to be /webui/realmname.

Is this a right observation? Are the plans for to introduce any additional routes or routes based on route.map?

Right now I would stay at least one more iteration with the old fcgi method and try to find out how the new application server is supposed to work.

Did I missed something?

--
Best regards
Daniel Hoffend


_______________________________________________
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users


--
Protect your environment -  close windows and adopt a penguin!



_______________________________________________
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users

Reply via email to