Closed bakfiets2 closed 3 years ago
Same exact error for me as well
snipeit version: v4.9.5 - build 4482 (master)
OS: Windows Server 2019 Windows IIS Server: 10.0.17763.1
LDAP enabled and working. AD user able to login Non AD Admin user created on setup works
All are unable to see anything in snipeit with the above error.
spun up snipe-it 4.8.0, identical issue. This means the issue is most probably environmental.
After 4 days of searching. No results yet. Checked a lot of right things. Tried 2 different servers. Not much to find about this error btw
for now, just to get out of the error (do not do this in production system) and to see what is going on, I commented out the following line 41 of C:\inetpub\wwwroot\snipe-it\vendor\laravel\framework\src\Illuminate\Auth\Middleware\Authenticate.php
// $this->authenticate($guards);
restart web server and things are looking good. So I can troubleshoot further.
Cool. Going to try that tomorrow!
So, we're starting to see a little bit of this with some of our customers (not-hosted). I don't have any definitive answers yet, but it's at least reproducible across multiple systems, which is a good start.
If you can tell me what happens if you run the following:
php artisan passport:install
php artisan migrate
php artisan passport:client --personal
log out, log back in, try to reproduce again, and tail the logs as you do.
We'll figure this out. Something changed, and it wasn't the version of Laravel, so I'm confident we can find the common thread here.
Never met forge :)
SQLSTATE[HY000] [1045] Access denied for user 'forge'@'localhost' (using password: YES)
If you see that, it means one of two things...
Either you didn't set your MySQL info in the .env, OR, you have a parse error higher up in the .env (weird characters that are not enclosed in quotes, for example) so that the .env cannot be read.
apologies, I was in another snipe 4.8 folder when I did this. went back to latest v4.9.5 - build 4482 (master) folder and those commands did not fix the original issue.
@yosiasz roger that - can you successfully create an API key through the web UI? (Go to your name in the top left, and then API keys)
yes I am able to create an API key (from top right)
So this is the same thing we're seeing on only self-hosted folks. Nothing big has changed in the last few versions of Snipe-IT, so I have to wonder if it's an environmental change? Do you know if you're running SELinux?
We are using IIS on Windows Server 2019. Not sure if that answers the question.
public function handle($request, Closure $next, ...$guards)
{
//echo implode("X",$guards);
$this->authenticate($guards); -->Commenting this out, makes it "work"
return $next($request);
}
It does :D
Can you show me the perms on your storage directory and subdirectories?
Sometimes we see highly conflated log errors because the log itself (or temp directories) are writable by the current user, but not the web server.
You can't realistically comment that out tho - It's literally what controls all permissions within the system.
Can all of you on the the thread let me know what specific version of PHP you're using? Wondering if maybe it's an esoteric artifact of a minor version change in PHP
PHP 7.4 nts.
I purposely gave IUSR full control on storage
I suspect, it is environmental php modules that were update such as ldap.
@yosiasz TYSM for your patience here. I know we run PHP 7.3 for all of our hosted customers.
I'd love to hear from others who are having this issue with respect to what version they're using. If we can figure out what's happening here, it would be a huge win for many of the folks who use this software.
@uberbrady can you reproduce this on your linux PHP 7.4 install?
@yosiasz I feel like we're getting closer. You're seeing it on windows, and the OP (and a few support - self-hosted - customers) are seeing it on linux, which definitely helps rule some things out. Suspecting it might be a PHP 7.4 issue, but we'll need to confirm. 7.3 -> 7.4 did some weird stuff that I'm not exactly in love with, and it might be that simple.
Folks - we've got all eyes on this one now. Any additional info you can provide is awesome, but at least know we're moving heaven and earth to at least reproduce this.
@yosiasz Really solid sleuthing on the guards thing. Again, not really tenable in production, but I think it may help us narrow this down a bit.
pointed latest to php v7.3 still same issue. Could be cached stuff on IIS. More reason for us to move away from IIS. php_ldap version change is what I suspect
It could be, but that's not what this feels like. We're seeing this (albeit rarely) on both IIS and Linux, so IIS (for once) isn't to blame :D It's something else, but I definitely appreciate all of your help in trying to track this down.
And FWIW, some people reporting this issue are not using any of the LDAP functions, so that shouldn't be an issue.
But, I mean, computers....
We'll keep working on it on our end.
@yosiasz I feel like we're getting closer. You're seeing it on windows, and the OP (and a few support - self-hosted - customers) are seeing it on linux, which definitely helps rule some things out. Suspecting it might be a PHP 7.4 issue, but we'll need to confirm. 7.3 -> 7.4 did some weird stuff that I'm not exactly in love with, and it might be that simple.
I Tried also installing on 7.2. No luck. Same error. Will try installing it again. The PHP version that comes with Plesk is having issues. So installed 7.2.33. Still no luck. Same error. It is on a VPS running on strato. I have 3 servers. Tried on 2 of them. One server has slighlty older software. Same error haha.
Computers are strange things...
BTW. i don't use LDAP
This works perfectly:
v4.8.0 - build 4186 (master) PHP 7.3.13
This works perfectly:
v4.8.0 - build 4186 (master)
PHP 7.3.13
Will give this a try tonight. Thnx
What's really baffling me here is that we still can't reproduce it anywhere. We have thousands of 4.9.5 instances deployed and we haven't seen this anywhere in our production systems or local development systems.
Please understand, I'm not doubting you - as I mentioned, you're not the only ones reporting this, but it's such a tiny number of cases that it makes it a real slog to troubleshoot. Even looking at the changes within the past few versions, we didn't change anything there that would affect anything like permissions, gates, sessions, etc. Plus the OP is saying this happened on 4.6.4, which is a very old version.
We had a self-hosted customer send over their database just so we could confirm it wasn't a failed migration or something, and it loaded up just fine. This is a real head-scratcher.
Can anyone on this thread try switching to the develop branch on a test install? (You should run migrations, as the DB has changed a little.) We're about to release v5 this week, and part of me doesn't want to spend too much time on this if it's somehow resolved in v5.
What's really baffling me here is that we still can't reproduce it anywhere. We have thousands of 4.9.5 instances deployed and we haven't seen this anywhere in our production systems or local development systems.
Please understand, I'm not doubting you - as I mentioned, you're not the only ones reporting this, but it's such a tiny number of cases that it makes it a real slog to troubleshoot. Even looking at the changes within the past few versions, we didn't change anything there that would affect anything like permissions, gates, sessions, etc. Plus the OP is saying this happened on 4.6.4, which is a very old version.
We had a self-hosted customer send over their database just so we could confirm it wasn't a failed migration or something, and it loaded up just fine. This is a real head-scratcher.
Big typo. Should be 4.9.0 and 4.9.6
Can anyone on this thread try switching to the develop branch on a test install? (You should run migrations, as the DB has changed a little.) We're about to release v5 this week, and part of me doesn't want to spend too much time on this if it's somehow resolved in v5.
Going to test it this evening! Wil do a clean install on v5
Big typo. Should be 4.9.0 and 4.9.6
Ah, thanks for the clarification!
Going to test it this evening! Wil do a clean install on v5
Thanks so much - I'm so sorry you folks are having this issue. I wish I had a smoking gun for you. Still trying to figure it out tho :(
Big typo. Should be 4.9.0 and 4.9.6
Ah, thanks for the clarification!
Going to test it this evening! Wil do a clean install on v5
Thanks so much - I'm so sorry you folks are having this issue. I wish I had a smoking gun for you. Still trying to figure it out tho :(
No big deal. I really would like this to work because it will make some things a lot easier. So no worries!
Hm, I was rubber-ducking this with @uberbrady and I think we might have an idea here?
First off, let's do the "IT 101" version:
What I'm thinking right now is that we did make some security header changes a few versions ago, specifically setting HSTS headers (which should default to off so it doesn't monkey anyone up if they don't support it, but it's possible that I donked something up when checking for that .env var).
I have a theory, but I'd love it if either of you can test this for me.
If you comment out this line (TEMPORARILY) : https://github.com/snipe/snipe-it/blob/master/app/Http/Kernel.php#L24
So change that line in /app/Http/Kernel.php
from
\App\Http\Middleware\SecurityHeaders::class,
to
// \App\Http\Middleware\SecurityHeaders::class,
clear your cookies, log out, and login again, do you still have the problem on v4.9.4 or 4.9.5?
GitHubA free open source IT asset/license management system - snipe/snipe-it
Hm, I was rubber-ducking this with @uberbrady and I think we might have an idea here?
First off, let's do the "IT 101" version:
* Trying in different browsers after clearing cookies, you see the same thing, correct? * Are you running any additional hardware or network appliances (load balancer, proxy, etc)?
What I'm thinking right now is that we did make some security header changes a few versions ago, specifically setting HSTS headers (which should default to off so it doesn't monkey anyone up if they don't support it, but it's possible that I donked something up when checking for that .env var).
I have a theory, but I'd love it if either of you can test this for me.
If you comment out this line (TEMPORARILY) : https://github.com/snipe/snipe-it/blob/master/app/Http/Kernel.php#L24
So change that line in
/app/Http/Kernel.php
from\App\Http\Middleware\SecurityHeaders::class,
to
// \App\Http\Middleware\SecurityHeaders::class,
clear your cookies, log out, and login again, do you still have the problem on v4.9.4 or 4.9.5?
GitHubsnipe/snipe-itA free open source IT asset/license management system - snipe/snipe-it
Same error. I tried with Safari. Firefox. Firefox on windows and Edge. No other network balancing stuff. Running PHP 7.2.33.
Is there something i can send you?
GitHubA free open source IT asset/license management system - snipe/snipe-it
DAMMIT. I was sure the HSTS stuff was it. Arglebargle.
This still feels like a header issue to me, like some new setting we introduced is causing the authentication/authorization headers to be stripped out when it's making the API calls.
Let me chew on this some more. Again, sorry for the hassle, and I really appreciate your patience.
Just happy with your support! If you need something let me know!
If you create an API token and run a curl command to an API endpoint (like /api/v1/users
) does that work? LMK if you need help figuring out how to do that.
IIS Windows 2019 snipe-it-4.9.0 PHP 7.3.13
Works
@yosiasz to clarify, you're saying 4.9.0 does work, but even with the change I proposed above, 4.9.5 does not?
There are (unfortunately) a ton of differences between 4.9.0 and 4.9.5: https://github.com/snipe/snipe-it/compare/v4.9.0...v4.9.5
It would be really helpful if we could determine the latest working version of 4.9.x where this issue wasn't a problem. That can at least narrow a few things down.
with 4.9.5 along with the changes you proposed above are not working
I am going through each version starting from 4.9.0 and testing each versions up to 4.9.4
4.9.1 is next
@yosiasz thank you so much - that will be enormously helpful!
If you create an API token and run a curl command to an API endpoint (like
/api/v1/users
) does that work? LMK if you need help figuring out how to do that.
Big error. Creating a API. Looks like some DB's are missing
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'snipe.oauth_personal_access_clients' doesn't exist (SQL: select * from oauth_personal_access_clients
order by id
desc limit 1)
/var/www/vhosts/ict.jellevansetten.nl/httpdocs/vendor/laravel/framework/src/Illuminate/Database/Connection.php#664
Illuminate\Database\QueryException
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'snipe.oauth_personal_access_clients' doesn't exist
/var/www/vhosts/ict.jellevansetten.nl/httpdocs/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php#63
Doctrine\DBAL\Driver\PDOException
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'snipe.oauth_personal_access_clients' doesn't exist
/var/www/vhosts/ict.jellevansetten.nl/httpdocs/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php#61
Try php artisan migrate
4.9.1 works!
php artisan migrate
And the next one
Trying to get property 'client' of non-object /var/www/vhosts/ict.jellevansetten.nl/httpdocs/vendor/laravel/passport/src/ClientRepository.php#81 ErrorException return $this->find(Passport::$personalAccessClient); }
return PersonalAccessClient::orderBy('id', 'desc')->first()->client;
}
/**
Run php artisan passport:client --personal
(You can use the default data it prompts you for there.)
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