Unlink a device from an admin account doesn’t work
This error means you're not authenticated as any user.
That's strange. I was logged in with Traccar Manager on my iPad.
I logged out and logged in newly. Now, it worked.
I’m experiencing the same issue.
When I log in through Traccar Manager using Face ID, I can access the system normally, but I cannot change user settings — including my own user settings. Whenever I try to make a change, I get the same error saying that I am not authenticated.
If I log out and then log in again using my email and password, everything works normally and I can modify the user settings without any problem.
There is another scenario where I can reproduce the same issue:
If I use Users → Login As / Enter to log in as another user, once I enter that user’s account, I cannot change anything either. Any attempt to modify settings results in the same authentication error.
So it seems that the problem may be related to the authentication/session created by Traccar Manager (especially when using Face ID) and also when using the “login as user” functionality.
The strange part is that logging out and logging in again with email and password immediately fixes the problem.
I’m using the latest version of Traccar.
Is this a known issue with the authentication/session handling in Traccar Manager?
jakarta.ws.rs.WebApplicationException: HTTP 401 Unauthorized
at org.traccar.api.security.SecurityRequestFilter.filter(SecurityRequestFilter.java:122)
at org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:108)
at org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:44)
at org.glassfish.jersey.process.internal.Stages.process(Stages.java:173)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:266)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:266)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:253)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:703)
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:422)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:374)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:355)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:309)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:202)
at org.eclipse.jetty.ee10.servlet.ServletHolder.handle(ServletHolder.java:754)
at org.eclipse.jetty.ee10.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1642)
at org.traccar.web.WebServer.lambda$initClientProxy$0(WebServer.java:131)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
at org.traccar.web.OverrideFileFilter.doFilter(OverrideFileFilter.java:49)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:89)
at org.traccar.web.OverrideTextFilter.doFilter(OverrideTextFilter.java:53)
at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:121)
at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:133)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1556)
at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:871)
at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:449)
at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:469)
at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:719)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1253)
at org.eclipse.jetty.server.Handler$Sequence.handle(Handler.java:859)
at org.eclipse.jetty.server.Server.handle(Server.java:197)
at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:804)
at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:420)
at org.eclipse.jetty.server.internal.HttpConnection$FillableCallback.succeeded(HttpConnection.java:1790)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:54)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:492)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.epcRunTask(AdaptiveExecutionStrategy.java:428)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:401)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:255)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:204)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:317)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:1009)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1240)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1194)
at java.base/java.lang.Thread.run(Thread.java:1474)
Update / Solution:
I found the solution in another topic on the forum and it fixed the problem for me.
I’m using Apache2 as a reverse proxy for Traccar. I added the following directive to the Apache2 reverse proxy configuration:
ProxyPreserveHost On
After adding it and reloading Apache2, the issue was completely resolved.
I can now log in through Traccar Manager using Face ID/token and modify user settings normally. The Users → Login As functionality also works correctly, and I no longer get the HTTP 401 authentication error.
So in my case, the issue was related to the Apache2 reverse proxy configuration.
Thanks!
This is likely related to the session origin-validation check added in December. Logging out and back in re-syncs it, which is why that fixes it. If you're behind a reverse proxy or reach the server via more than one hostname, that's the most likely trigger - let us know your setup if you can reproduce it again.
Yes, I can reproduce it consistently.
My setup is:
- Traccar 6.15 running on a virtual machine (VM)
- Debian 13
- MariaDB running locally on the same VM
- Apache2 used as a reverse proxy
- Traccar running locally on port 8082
- Users access Traccar through an HTTPS hostname, with Apache2 forwarding the requests to localhost:8082
- Traccar Manager is used for token/Face ID authentication
- Apache2 also proxies the WebSocket connection for /api/socket
The issue occurred when logging in through Traccar Manager using a token/Face ID. The login worked, but administrative actions such as editing users returned HTTP 401 Unauthorized.
The same thing happened when using Users → Login As. After logging in as another user, I could not modify any settings.
Logging out and logging back in with email/password temporarily fixed the issue, which seems to match your explanation about the session origin validation.
I found the solution in another topic: adding
ProxyPreserveHost On
to the Apache2 reverse proxy configuration.
After adding it and reloading Apache2, the issue was completely resolved. I can now use token/Face ID login and modify users normally, including after using Login As.
So in my case, it was indeed related to the reverse proxy/session origin validation.
Thanks for the explanation!
Same for me:
- Traccar 6.15 running on a virtual machine (VM, Ubuntu)
- mySQL DB running locally on the same VM
- Apache2 used as a reverse proxy
- Traccar running locally on port 8082
- Users access Traccar through an HTTPS hostname, with Apache2 forwarding the requests to localhost:8082
- Traccar Manager is used for token/Face ID authentication
- Apache2 also proxies the WebSocket connection for /api/socket
Adding of
ProxyPreserveHost on
to the Apache2 config file for my site and reloading Apache2 seems to have solved the problem.
Thanks for the solution, Junior_Man!
PS: my full Apache2 config file (site name replaced by my-site):
<VirtualHost *:80>
ServerName my-site.de
Redirect / https://my-site.de/
RewriteEngine on
RewriteCond %{SERVER_NAME} =my-site.de
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerName my-site.de
ServerAdmin webmaster@localhost
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /api/socket ws://localhost:8082/api/socket
ProxyPassReverse /api/socket ws://localhost:8082/api/socket
ProxyPass / http://localhost:8082/
ProxyPassReverse / http://localhost:8082/
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/my-site.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/my-site.de/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>
Hi,
Im trying to unlink a device from an admin account, but it doesn’t work.
The device belongs to a group.
According to the documentation, admins should be able to unlink devices from themselves (last point under user limits here: https://www.traccar.org/user-management/).
This are the error details (more info) in the error notification (when I try to unlink the device in the user settings -> username -> connections):