Hello Oliver
thanks for your clarification. That's what I thought and tbh makes
sense. Every additional dynamic could make things quite chaotic. I'll
adjust my ansible configuration templates for the future to redirect
some old entry urls.
best regards
Daniel
Am 20.07.2025 um 19:59 schrieb Oliver Welter:
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
_______________________________________________
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users
