Closed bakfiets2 closed 3 years ago
Yes, same issue (unauthorized).
Can you please post instructions for installing the Alpha/Dev channel build (v5)? I will give that a go.
@mce-reggie Did you try updating your COOKIE_DOMAIN to your actual domain though? (without http/https) I'm trying to figure out whether this is a server environment problem, a configuration problem, or a code problem.
Upgrading to v5 dev would be the same, except you check out the develop
branch (or one of the dev release tags) instead of the master
branch.
Yes, I tried updating the COOKIE_DOMAIN and also tried setting it to "null" clearing cookies and cache each time. Still the same issue.
Attached is a screenshot of the debug error.
What did you set the cookie domain to, specifically?
If clearing your browser cookies/cache broke it again, it's almost certainly an .env variable, since that's the only part of this system that would care about your browser session.
The server's FQDN is thd.mce.local. I set COOKIE_DOMAIN to mce.local (although I also tried the FQDN as well).
When I have time I will bring up a development instance on the same server using a fresh .env file.
Any updates?
Hi there, glad I found this thread. Just performed a server migration and backed up my snipe-it instance (database, .env, etc) that was running great for quite some time. Restored it to a nearly identical environment and ran into this unauthorized error as well. I have the entire snipe-it directory backed up, but no longer have access to the original server that was successfully running snipe-it. The server was running Debian 9 or 10, using php 7.2, nginx, ssl, no ldap, do not recall the snipe-it version (old, maybe a year ago's release). The new server is running Debian 10, using php 7.3, nginx, ssl, no ldap, and the current master branch (did a git clone this time). I restored the mariadb database, the .env, uploaded files, and oauth keys, and performed the artisan migrate and config clear. I'm able to access the site as well as login to my original user account that I had on the original install. No records are showing up anywhere (I've checked the database and they do indeed exist). Debug is showing the same Unauthorized. error that you all have been referencing in this thread.
Hope this is helpful. I'll probably try to restore tomorrow with the entire snipe-it directory I had backed up instead of the newer branch, and potentially try to revert to php 7.2 just to properly replicate the original server's environment. Let me know if you'd like any further details.
I also migrated after successfully updating everything and the lastest on another server and now: get the same error.
I'm still completely unable to reproduce this on any local or customer hosted instances :(
Because it's not happening on customer instances, this leads me to believe it's either a server setting or some random cached file. That said, we are seeing it with a very small handful of support-only customers, but at least one reported it starting from v4.9.3-4.9.5. The only thing I can think of that should have mattered there is the new consolidated SecurityHeaders, but commenting out that middleware doesn't seem to help either.
I desperately wish I could reproduce this - I've been trying for weeks now, with zero luck.
What I think is likely happening is that something is failing high enough in the stack (again, due to a server config or cached files) that's causing it to not be able to process the authentication because it can't complete loading the framework properly.
If someone has the time, can you change the method in app/http/middleware/Authenticate.php
FROM:
public function handle($request, Closure $next)
{
if ($this->auth->guest()) {
if ($request->ajax()) {
return response('Unauthorized.', 401);
} else {
return redirect()->guest('login');
}
}
return $next($request);
}
TO:
public function handle($request, Closure $next)
{
if ($this->auth->guest()) {
\Log::info('This is an auth->guest() call');
if ($request->ajax()) {
\Log::info('Unauthorized ajax call :(');
return response('Unauthorized.', 401);
} else {
\Log:: info('This is not an ajax call but is unauthorized. Redirect to web login.');
return redirect()->guest('login');
}
}
\Log::info('This is NOT an auth->guest() call');
return $next($request);
}
and then tail your log files while debug is turned on? (All I've done here is added some additional logging which should at least help diagnose what's happening a little better.)
Hi @snipe,
we are having the same issue using v5.0.4, it started around v4.9.5. I have changed the mentioned method and enabled debug mode. That's the output:
[2020-11-05 09:50:20] production.ERROR: The resource owner or authorization server denied the request. {"exception":"[object] (League\\OAuth2\\Server\\Exception\\OAuthServerException(code: 9): The resource owner or authorization server denied the request. at /var/www/html/snipe-it/vendor/league/oauth2-server/src/Exception/OAuthServerException.php:243)
[stacktrace]
#0 /var/www/html/snipe-it/vendor/league/oauth2-server/src/AuthorizationValidators/BearerTokenValidator.php(84): League\\OAuth2\\Server\\Exception\\OAuthServerException::accessDenied('Access token is...')
#1 /var/www/html/snipe-it/vendor/league/oauth2-server/src/ResourceServer.php(84): League\\OAuth2\\Server\\AuthorizationValidators\\BearerTokenValidator->validateAuthorization(Object(Laminas\\Diactoros\\ServerRequest))
#2 /var/www/html/snipe-it/vendor/laravel/passport/src/Guards/TokenGuard.php(184): League\\OAuth2\\Server\\ResourceServer->validateAuthenticatedRequest(Object(Laminas\\Diactoros\\ServerRequest))
#3 /var/www/html/snipe-it/vendor/laravel/passport/src/Guards/TokenGuard.php(131): Laravel\\Passport\\Guards\\TokenGuard->getPsrRequestViaBearerToken(Object(Illuminate\\Http\\Request))
#4 /var/www/html/snipe-it/vendor/laravel/passport/src/Guards/TokenGuard.php(94): Laravel\\Passport\\Guards\\TokenGuard->authenticateViaBearerToken(Object(Illuminate\\Http\\Request))
#5 /var/www/html/snipe-it/vendor/laravel/passport/src/PassportServiceProvider.php(283): Laravel\\Passport\\Guards\\TokenGuard->user(Object(Illuminate\\Http\\Request))
#6 [internal function]: Laravel\\Passport\\PassportServiceProvider->Laravel\\Passport\\{closure}(Object(Illuminate\\Http\\Request), NULL)
#7 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Auth/RequestGuard.php(58): call_user_func(Object(Closure), Object(Illuminate\\Http\\Request), NULL)
#8 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Auth/GuardHelpers.php(60): Illuminate\\Auth\\RequestGuard->user()
#9 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Auth/Middleware/Authenticate.php(62): Illuminate\\Auth\\RequestGuard->check()
#10 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Auth/Middleware/Authenticate.php(41): Illuminate\\Auth\\Middleware\\Authenticate->authenticate(Object(Illuminate\\Http\\Request), Array)
#11 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(171): Illuminate\\Auth\\Middleware\\Authenticate->handle(Object(Illuminate\\Http\\Request), Object(Closure), 'api')
#12 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(105): Illuminate\\Pipeline\\Pipeline->Illuminate\\Pipeline\\{closure}(Object(Illuminate\\Http\\Request))
#13 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Routing/Router.php(683): Illuminate\\Pipeline\\Pipeline->then(Object(Closure))
#14 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Routing/Router.php(658): Illuminate\\Routing\\Router->runRouteWithinStack(Object(Illuminate\\Routing\\Route), Object(Illuminate\\Http\\Request))
#15 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Routing/Router.php(624): Illuminate\\Routing\\Router->runRoute(Object(Illuminate\\Http\\Request), Object(Illuminate\\Routing\\Route))
#16 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Routing/Router.php(613): Illuminate\\Routing\\Router->dispatchToRoute(Object(Illuminate\\Http\\Request))
#17 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(170): Illuminate\\Routing\\Router->dispatch(Object(Illuminate\\Http\\Request))
#18 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(130): Illuminate\\Foundation\\Http\\Kernel->Illuminate\\Foundation\\Http\\{closure}(Object(Illuminate\\Http\\Request))
#19 /var/www/html/snipe-it/vendor/barryvdh/laravel-debugbar/src/Middleware/InjectDebugbar.php(65): Illuminate\\Pipeline\\Pipeline->Illuminate\\Pipeline\\{closure}(Object(Illuminate\\Http\\Request))
#20 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(171): Barryvdh\\Debugbar\\Middleware\\InjectDebugbar->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#21 /var/www/html/snipe-it/app/Http/Middleware/SecurityHeaders.php(26): Illuminate\\Pipeline\\Pipeline->Illuminate\\Pipeline\\{closure}(Object(Illuminate\\Http\\Request))
#22 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(171): App\\Http\\Middleware\\SecurityHeaders->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#23 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/TransformsRequest.php(21): Illuminate\\Pipeline\\Pipeline->Illuminate\\Pipeline\\{closure}(Object(Illuminate\\Http\\Request))
#24 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(171): Illuminate\\Foundation\\Http\\Middleware\\TransformsRequest->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#25 /var/www/html/snipe-it/app/Http/Middleware/CheckForDebug.php(25): Illuminate\\Pipeline\\Pipeline->Illuminate\\Pipeline\\{closure}(Object(Illuminate\\Http\\Request))
#26 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(171): App\\Http\\Middleware\\CheckForDebug->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#27 /var/www/html/snipe-it/app/Http/Middleware/CheckForSetup.php(26): Illuminate\\Pipeline\\Pipeline->Illuminate\\Pipeline\\{closure}(Object(Illuminate\\Http\\Request))
#28 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(171): App\\Http\\Middleware\\CheckForSetup->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#29 /var/www/html/snipe-it/vendor/fideloper/proxy/src/TrustProxies.php(57): Illuminate\\Pipeline\\Pipeline->Illuminate\\Pipeline\\{closure}(Object(Illuminate\\Http\\Request))
#30 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(171): Fideloper\\Proxy\\TrustProxies->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#31 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/View/Middleware/ShareErrorsFromSession.php(49): Illuminate\\Pipeline\\Pipeline->Illuminate\\Pipeline\\{closure}(Object(Illuminate\\Http\\Request))
#32 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(171): Illuminate\\View\\Middleware\\ShareErrorsFromSession->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#33 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Session/Middleware/StartSession.php(56): Illuminate\\Pipeline\\Pipeline->Illuminate\\Pipeline\\{closure}(Object(Illuminate\\Http\\Request))
#34 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(171): Illuminate\\Session\\Middleware\\StartSession->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#35 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/CheckForMaintenanceMode.php(63): Illuminate\\Pipeline\\Pipeline->Illuminate\\Pipeline\\{closure}(Object(Illuminate\\Http\\Request))
#36 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(171): Illuminate\\Foundation\\Http\\Middleware\\CheckForMaintenanceMode->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#37 /var/www/html/snipe-it/vendor/barryvdh/laravel-cors/src/HandlePreflight.php(29): Illuminate\\Pipeline\\Pipeline->Illuminate\\Pipeline\\{closure}(Object(Illuminate\\Http\\Request))
#38 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(171): Barryvdh\\Cors\\HandlePreflight->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#39 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(105): Illuminate\\Pipeline\\Pipeline->Illuminate\\Pipeline\\{closure}(Object(Illuminate\\Http\\Request))
#40 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(145): Illuminate\\Pipeline\\Pipeline->then(Object(Closure))
#41 /var/www/html/snipe-it/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(110): Illuminate\\Foundation\\Http\\Kernel->sendRequestThroughRouter(Object(Illuminate\\Http\\Request))
#42 /var/www/html/snipe-it/public/index.php(58): Illuminate\\Foundation\\Http\\Kernel->handle(Object(Illuminate\\Http\\Request))
#43 {main}
"}
I played around with the config (I think I activated all the options), then I played with the LDAP-settings and in the end I did a
sudo -u www-data php upgrade.php
And now it works for me again! :) I am on Snipe-IT Version v5.0.5-pre build 5457 now.
does anyone have found a solution, i am pretty much stuck
@stefantrav Do you use LDAP? And are you on the same version as I am? After upgrading and changing some LDAP-options it started to work again for me.
@saschafoerster never mind, it turned out that i was missing an php-extention (tecnickcom/tc-lib-barcode 1.15.20 requires ext-bcmath * -> it is missing from your system)
never had any upgrade issues within 4.x, but with 5.x i've run the upgrade.php again and it worked this time
Just here to confirm that running php upgrade.php
as the www-data user has fixed my installation. Not sure what it did extra outside of what I had already done (mostly following steps from https://snipe-it.readme.io/docs/moving-snipe-it), but it did indeed resolve the issue.
Snipe-IT DocumentationMoving/migrating Snipe-IT to a new server should be a pretty painless process. You really only have a few things to worry about: Your .envYour databaseYour uploaded filesYour OAuth keys The easiest way to handle this is to simply run a backup through your Snipe-IT admin panel at Admin > Backups,...
@flexional Thanks so much for confirming that, Kyle.
So far, it seems to me there are two main causes for this behavior:
Something that wasn't run or a cache that should have been cleared that didn't get cleared through manual upgrading means that does get run when you run php upgrade.php
.
If you look at upgrade.php , it does the following (in this order):
bootstrap/cache/compiled.php
bootstrap/cache/services.php
bootstrap/cache/config.php
php artisan config:clear
, etc.composer install --no-dev --prefer-source
, either as global composer or local composer, depending on which one it detects, and then outputs the resultsphp artisan passport:install
.So if any of these steps weren't done manually (aka when not using php upgrade.php
), and running the upgrade script fixes it, we're closer to understanding what's happening here.
OR
The required extensions actually haven't changed between v4 and v5, but there were some you could get away with not having before that the system now requires on a deeper level. (You should have had them installed anyway because they were in the requirements, but I digress... )
Specifically, the way LDAP was rewritten makes it a service provider now (which I hate), which means it loads up some of that LDAP functionality even if you're not doing an LDAP thing or if you don't even have LDAP enabled. The prior behavior was to only invoke LDAP methods if you were trying to do an LDAP thing. That's not the case anymore, so if you don't have the php-ldap
extension, it breaks in weird, horrible ways that don't explain the actual real problem very much at all.
I'll likely be writing an integrity-checker shortly that at least walks through the requirements and confirms whether or not you have the extensions installed, but that too is fraught with peril. In the meantime, I'm adding some text to the docs to address this specific issue.
Since it seems like everyone is sorted on this thread, I'm going to close it for now.
Sorry, @bakfiets2 - I realized you didn't get an answer - I'd look at my comment. Even if you're not running LDAP, you still need the php-ldap
extension installed and enabled for your web server.
Nope. It did not solve the issue. Even on the new version. ldap is enabled in the PHP settings. Same error...
Can you confirm you've checked all of the things in my comment?
So far, the only reasons we've seen this happen is summarized by my comment. It's either missing extensions (not just php-ldap is required) or those caches mentioned in the "smoking gun" section of the comment.
There was indeed a ldap problem. It was loaded but not on the composer side of this plesk server. But that still does not solve the error. Also deleted the files you mentioned in /bootstrap/cache.
Going to try a reinstall of snipe to see of this fixes the error. No errors btw when running php upgrade.php
It appeared as though I didn't have the php-json extension installed on my system somehow. I installed that and ran upgrade.php and everything is working now under the new version.
Thanks for persevering!
I don't know where to search for problems. Every extension is runnung. Server is running php7.4 from CLI and also on the web side. php upgrade.php does not solve anything. It says everything is just fine. See below the PHPinfo.
It would be great to run this software. But i need to stop trying i think because it is costing to much time to get it running...
http://ict.jellevansetten.nl/info.php
Got it figured out. There are some strange things in Plesk Onyx. When uploading snipe by FTP, it is missing some files i gues. Did a git pull on the already running installation from the Plesk control screen. Added the PHP extension by hand in de PHP settings from the domain inside plesk. Run the php upgrade.php and everything is running.
So when using plesk, pull it from git with the Git extension from plesk. Will try a new installation tomorrow to see if i can do the trick again
Excellent - thanks so much for following up. FWIW, I made some changes to the upgrade script this week that should help identify missing extensions a little easier.
Found another thing. After installing snipe again. i get the same error. If i do a pull. And run upgrade.php it starts downgrading the composer. I suspect that Plesk is updating the composer during the iniatal install of composer on the domain.
Als the check you integrated has a strange thing. It says everything is there. And then says it is missing a few php extensions.
β bcmath is installed!
β curl is installed!
β fileinfo is installed!
β gd is installed!
β json is installed!
β ldap is installed!
β mbstring is installed!
β mysqli is installed!
β openssl is installed!
β PDO is installed!
β tokenizer is installed!
β xml is installed!
β zip is installed!
PHP extension MISSING: php-ldap
PHP extension MISSING: php-json
PHP extension MISSING: php-fileinfo
PHP extension MISSING: php-openssl
Hm, okay, Iβll take a look
The upgrade script should be fixed on master now. (I had left in a duplicate block of code)
Cool. Will do a pull. Thnx!
Lemme know if you run into anything else weird. :)
I have the Same error can you tell me how i can fix this
@Jannik2017 without knowing what version you're on and whether you've tried any of the solutions in this thread, you can see how it will be difficult for us to help you right?
i am on the Version 5.0.6
@Jannik2017 And? What did you try from the replies above?
i have checked the perms and the packeges and cleared the cache
Dude, you're killing me. I need information in order to help you. How did you check the packages? Did you do the things in the FAQ? https://snipe-it.readme.io/docs/installation-issues#table-listing-pages-load-with-401-unauthorizedunauthenticated - if so, which ones? Did you try running upgrade.php
? If so, what's the output?
Also, in the future, if an issue is closed, please create a new issue and fill in all of the questions in the new issue form. (When you reply to older, closed threads, it sends an email notification to everyone who ever participated in it, which can be pretty annoying to have happen on a thread that's been resolved.)
Snipe-IT DocumentationCommon installation/upgrading issues and solutions
i didnt found any solution for the Problem here https://snipe-it.readme.io/docs/installation-issues#table-listing-pages-load-with-401-unauthorizedunauthenticated i have already checked this page i didnt tryed upgrading should i have to ?
Snipe-IT DocumentationCommon installation/upgrading issues and solutions
upgrade php says PHP Fatal error: Uncaught Error: Call to undefined function posix_getpwuid() in
@Jannik2017 - a google search on that error points me to this: https://github.com/snipe/snipe-it/issues/7888
i have just seen that
i have the same problem again after running upgrade.php
Same problem with v5.0.11 because of ldap extension is absent.
Used workaround // $this->authenticate($guards);
and removed ldap from composer.json
I wonder if it is possible to make this extension optional.
Wich platform and OS? Shared hosting?
Yes, shared hosting and they are refusing to install ldap.
Linux version 3.10.0-962.3.2.lve1.5.39.el7.x86_64 (mockbuild@buildfarm02.cloudlinux.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) ) #1 SMP Thu Sep 17 06:10:33 EDT 2020
Please confirm you have done the following before posting your bug report:
Describe the bug Fresh install of Snipe-It on a server Running Plesk Onyx. PHP Composer installs fine. Tried installing 4.8.0 and 4.8.5. Tried all PHP versions from 7 and up.
The thing is. If i want to add a Category. Lets say. In Licenses. The drop down menu tells me that the Results could not be loaded. If i try to add the category the window says: Server Error : Unauthorized
To Reproduce Steps to reproduce the behavior:
Server (please complete the following information):
Desktop (please complete the following information):
Error Messages Version v4.9.4 - build 4437 (master) Snipe-IT is open source software, made with love by @snipeitapp. 7.4.10358ms4MB5.5.50productionnlGET api/v1/categories/{item_type}/selectlist