Accessing API on Windows

[wq949966]

Please confirm you have done the following before posting your bug report:

• [ Yes] I have enabled debug mode
• [ Yes] I have read checked the Common Issues page

Describe the bug
Accessing API from Postman (or any other way). We get an error which says:

"error": "Unauthorized or unauthenticated."

To Reproduce
Steps to reproduce the behavior:

1. Install 5.1 on Windows
2. Login as admin and create an API Key
3. Use the Key in Postman as per documentation
4. See error

Expected behavior
Should return the list of Users
Screenshots
If applicable, add screenshots to help explain your problem.

Server (please complete the following information):

• Snipe-IT Version : Version v5.1.1 - build 5811 (master)
• OS: Windows Server 2019
• Web Server: IIS
• PHP Version : 7.4

Desktop (please complete the following information):

• OS: Windows 10
• Browser : Chrome
• Version NA

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Error Messages
-NA

Additional context

• Is this a fresh install or an upgrade? - Fresh
• What OS and web server you're running Snipe-IT on - Windows 2019/ 10
• What method you used to install Snipe-IT: Git
• Include what you've done so far in the installation, and if you got any error messages along the way.- No - System in active use
• Indicate whether or not you've manually edited any data directly in the database - NO

Add any other context about the problem here.

Please do not post an issue without answering the related questions above. If you have opened a different issue and already answered these questions, answer them again, once for every ticket. It will be next to impossible for us to help you.

[welcome]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

[snipe]

Please post your curl request. Usually when we see this, it's because you're missing a header in your Postman or cURL request.

[wq949966]

curl --location --request GET 'https://snipeit.smglegal.co.uk/api/v1/users'
--header 'Authorization: Bearer fake_long_bearer_token_string'
--header 'Content-Type: application/json'
--header 'Accept: application/json'
--header 'Cookie: snipeit_session=ZrhHNNSCHfraed97wH8iRUMvvtfE57bafJlGJ87U'

[wq949966]

HI @snipe - Thanks for the quick response! Please see my request above copied from Postman. I have followed the tutorial. The software itself works flawlessly. Its just the APIs which are not accessible.

[infotronicx]

Hi,
We are also getting the same issue.

---

curl --location --request GET 'http:https://192.168.29.120:9060/api/v1/hardware' \
--header 'Authorization: Bearer extremely_long_bearer_token_string' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Cookie: snipeit_session=45XDbfaDF1URtM7VQrXhaahn1ixZdOEdwz7nnlhM'

---

"error": "Unauthorized or unauthenticated."

[uberbrady]

First off - please don't post live Bearer tokens - I edited those down for both of you folks, hope you don't mind.

My best guess as to what's going on here is that you're confusing the Auth system by sending both an Authorization header and a Cookie with a snipeit_session in it. If you look at our API docs here: https://snipe-it.readme.io/reference#hardware-list the sample code doesn't have the cookie part in it, just the Authorization header. The Accept header certainly isn't going to hurt you (and is generally good practice), but since GET requests have no body, the Content-Type header isn't going to do you any good.

Snipe-IT Documentation

Overview

Snipe-IT is a free, open source IT asset management system. Features include management of assets, users, licenses, accessories, consumables and components, as well as two-factor authentication, LDAP/AD syncing, and asset acceptance confirmation.

[snipe]

To the folks having issues here, can you cURL our our develop demo server? (You don't need to share the results with us, it's just demo data, but I'm curious to see if it's reproducible there.)

curl --request GET \
  --url 'https://develop.snipeitapp.com/api/v1/hardware' \
  --header 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6ImVmMGVhY2Y4MjAyYzgwZWI2M2JkNmIwZDc0OGYwY2FkYzU2Y2ZlMzgyNzY4ODY0N2EwNmU4ZTBlNmYwZDgwODNjZmMyMzI2YWYyYTZlMTFkIn0.eyJhdWQiOiIxIiwianRpIjoiZWYwZWFjZjgyMDJjODBlYjYzYmQ2YjBkNzQ4ZjBjYWRjNTZjZmUzODI3Njg4NjQ3YTA2ZThlMGU2ZjBkODA4M2NmYzIzMjZhZjJhNmUxMWQiLCJpYXQiOjE0OTMzMzI2MjgsIm5iZiI6MTQ5MzMzMjYyOCwiZXhwIjoxODA4ODY1NDI4LCJzdWIiOiIyIiwic2NvcGVzIjpbXX0.NU7ZRIt-d4b0o8uv9ipo1vSWcg1svbmPp47kHErafm9iuK4FjygKd2_4Hp73HKAmjiYcEn3r39pwNh2t9BMFnTXv0KeDGC8zfZ9z7OJN_a59LPoarWBFzCsYETyAm-CeeFnfdj9Cr0ZeGOnnaPuWPYxicwKFeqJI4Hn8nCymcamDGE0u4WOO95ihGOAen4_fqpj-kkBDsvsGhB-cQxeuKdlbvO1yOsKmgQv-kQuxiFMn1zgU7P02mC6XXrbw6jTm7JOaBSbvqSwNtsrSKZkim1jxLsQ4dm36lFmeMkU6hZvNSUnxg8JwbmoxQ_3tZlG3IJh3Sc9ZUi-AEAQ4bbGzi_xNS9fenIdzLDaSiv_esYyNOYXqOuSBk8Yr-720N9OcVjGLnPrV3RtmPisV1aLFgKWLImtlyQgUq3d5LA3QXz8Q_8isvO9Am1u8ri2plbHGJLJ6GRW_mYcBEYMwUozaeXTUe_FUSSO8gpGtO9Hpa5SbERY272_tojyVXpYPaPdUYYmS9CP332jBNESPT8wGwpOM-iddeVo_n82w3dHmDEdp1Brbs3_vKk0AcgvDLsAbd4dZZO-UqddVx6SDb3HLw1Pmw1wGGYHA6w8wWQAiS9kg2xMcz5i75HOULaN3miqYvcPCvHpI2CBfuvdplI8QNm_XzFPmoQRu_5kR8knzla4'

(Brady is right to suggest never posting bearer tokens in public, but this one is already public in our API docs)

[wq949966]

Thanks @uberbrady for editing my post.

@snipe - I have tried accessing the demo site. See my output below. I get exactly the same from my internal site (login):

    <title>Redirecting to https://develop.snipeitapp.com/login</title>
</head>
<body>
    Redirecting to <a href="https://develop.snipeitapp.com/login">https://develop.snipeitapp.com/login</a>.
</body>

[infotronicx]

Hi, It works properly with demo server but when deployed locally it is giving this error. Pls check API code. WAMP installation locally API test throws unauthorised error. We tried all options but there some issue with latest release API code. Regards,

…

On Sat, 20 Feb 2021, 10:09 pm snipe, ***@***.***> wrote: @uberbrady <https://github.com/uberbrady> You have to send both content-type and accept headers for Passport to work properly. (I know, it's dumb.) To the folks having issues here, can you cURL our our develop demo server? See the API docs Brady just linked to - if you can use the "Try it" button and then copy the curl command it shows you in the right-side panel, that would be helpful. (You don't need to share the results with us, it's just demo data, but I'm curious to see if it's reproducible there.) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9157 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAUEC3I56BF2RFIQZAMSL3S77QTHANCNFSM4X2FL4WQ> .

[snipe]

@infotronicx We have not made any changes to the API's authorization since v5. If it works with the demo server, then it works. This seems more environmental to me, as the code you deploy locally is the exact same code we host on the demo.

[snipe]

Can you both run the upgrade.php script and show me the output?

@wq949966 - that's... interesting. Possible you have a firewall or something running that might be stripping out headers?

[infotronicx]

Can you please eloborate "unauthenticated or unauthorized" error reasons ? and points where we can check to resolve the issue.

…

On Sat, 20 Feb 2021, 11:42 pm snipe, ***@***.***> wrote: @infotronicx <https://github.com/infotronicx> We have not made any changes to the API's authorization since v5. If it works with the demo server, then it works. This seems more environmental to me, as the code you deploy locally is the exact same code we host on the demo. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9157 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAUEC3GISA4DKUA7PDZFTDS773R3ANCNFSM4X2FL4WQ> .

[infotronicx]

Sure will share with you soon.

…

On Sat, 20 Feb 2021, 11:44 pm snipe, ***@***.***> wrote: Can you both run the upgrade.php script and show me the output? @wq949966 <https://github.com/wq949966> - that's... interesting. Possible you have a firewall or something running that might be stripping out headers? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9157 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAUEC7UUGTUDWIBYDDT4C3S7732HANCNFSM4X2FL4WQ> .

[snipe]

@infotronicx also please try generating a new token and trying with that. If you run into any issues while generating, please share them. I'm having to do a lot of guesswork here.

[wq949966]

Thank @snipe - I will try on the server itself (removing firewall) to avoid further wasting your time! Its a fantastic system. Thank you!

[snipe]

@wq949966 Or even try at home, or somewhere that's not on your usual network maybe? Just trying to rule some stuff out here. That redirect that you're seeing typically only happens when you're not sending the JSON headers. The app thinks it's a web (vs API) request, so it redirects you to a login.

[wq949966]

Hi @snipe - I now have the same result as @infotronicx -

1. I can get the API result from Snipe-It demo API
2. I have "Unauthorized or unauthenticated." when trying exactly the same against my internal site

I am using postman now but removed the cookies (turning off CookieJar). Removing the cookie helped get the result from the Demo site. But no luck with internal setup :(

[snipe]

@wq949966 thanks very much for that additional info. I can't reproduce this anywhere, but at least the behavior is consistent between the two of you, so that's kinda something.

Can you do a git pull and then a php update.php and show me the output? That script (in addition to updating your version) also tries to check for any missing PHP extensions that previous versions would have glossed over and permitted.

[wq949966]

Hi @snipe - I did an update just before I saw your post!

I am trying against version - Version v5.1.1 - build 5811 (master).

[snipe]

@infotronicx do your stats match the same at @wq949966? Both windows servers, etc?

I'd love to see the output of a php -m to show me what modules your PHP is compiled with (or has enabled).

The only other time we've seen this is when there are missing modules/libraries. We don't have a great way to check for this. and Laravel (or Snipe-IT maybe) fail very hard at explaining that that's why it's failing, because it's breaking so far up in the stack, the error logging system in Laravel doesn't even know how to handle it.

The reason we added the modules check in the upgrade.php is specifically to address missing libraries that can cause this issue. The upgrade script checks for PHP extensions/libs that we KNOW the system will break without.

If it's libraries, we usually see the symptoms as the listing tables in the web GUI not loading, but I'm not ruling it out.

[wq949966]

@snipe I will send the output pf php-m later today as I need to VPN to the server to run it.

[snipe]

@wq949966 well, so it's interesting.... We have, perhaps, two different issues here.

If you get "Unauthorized" from the demo server, which is a known good working server, something here still feels environmental. (Our entire API demo documentation stuff would fall over if the demo API was borked, so it seems unlikely whatever is going on is in Snipe-IT itself). That said, we still want to help you two figure out how to make this work.

@uberbrady On Monday when you're back at work, can you fire up the dusty Windows machine and see if you can reproduce this from a Windows CLI? Maybe there's some additional header that now needs to be passed if you're running on a windows machine?

[wq949966]

Hi @snipe ...

Output of PHP -m as below:

C:\inetpub\wwwroot\snipe-it-dev>php -m
[PHP Modules]
bcmath
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
gd
gettext
hash
iconv
imap
json
ldap
libxml
mbstring
mysqli
mysqlnd
openssl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
readline
Reflection
session
SimpleXML
soap
SPL
standard
tidy
tokenizer
wincache
xml
xmlreader
xmlrpc
xmlwriter
zip
zlib

[Zend Modules]

[wq949966]

Also note that today I tried the same commands on the server itself. Remote call to demo worked while the call to local installation still reported unauthorzed.

[infotronicx]

C:\wamp\www\snipe-it>php -m
[PHP Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
gd
gettext
gmp
hash
iconv
imap
intl
json
ldap
libxml
mbstring
mysqli
mysqlnd
openssl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
readline
Reflection
session
SimpleXML
soap
sockets
SPL
standard
tokenizer
wddx
xml
xmlreader
xmlrpc
xmlwriter
xsl
zip
zlib

[Zend Modules]

[infotronicx]

No issue with demo server only issue with local server.

[infotronicx]

Same issue on local server, checking with postman installed on local server
{"error":"Unauthorized or unauthenticated."}

[wq949966]

Hi @snipe anything further on this please? I have upgraded to absolutely latest release now and still no luck with the API. Other than that , the software is absolutely fantastic.

[snipe]

@inietov @Godmartinz Can you take a look at this one with your new windows machines?

I know we have tons of users who access the API using Windows (via Postman, Powershell, etc), so I can't imagine how this could be on our end, but I'm at a loss.

[uberbrady]

@infotronicx @wq949966 - hey folks, if you paste your token into https://jwt.ms (they say that they don't let your token data hit the server, but if you wanted to delete your token after doing so, that could be smart), do you get a weird value for the 'expiration date'?

Specifically, in "Decoded Token" you should see a value "exp" - what does that have? And if you click on the 'Claims' tab, you should see the expiration date in a more verbose (and much more readable) format - what do you get there?

Another option I wanted to float was maybe checking out v5.1.2 explicitly, instead of 'master' - do you have the problem there as well?

The reason I'm asking these questions is that I'm wondering if some changes we might have made to our Date libraries may have only affected Windows users somehow...

jwt.ms: Welcome!

[newbie-admin]

@uberbrady @snipe

Hello fellows,

Since my ticket was marked as duplicate to this one, will have to continue troubleshooting here.

Brief resume:

#9312

Our solution is not configured on Windows/IIS , but on Ubuntu 18.04 with Apache.
Server (please complete the following information):

Snipe-IT Version : v5.0.12 build 5705
OS: Ubuntu 18.04
Web Server: Apache
PHP Version : 7.2.24-0ubuntu0.18.04.7

Reverse Proxy - NGinx
Azure AD - SAML integration for user logins

Hitting the API with Postman - > Headers fields as requested in your API docs:

"authorization": "Bearer APIKEY",
"accept": "application/json" or "application/x-www-form-urlencoded",
"content-type": "application/json"

Result - > 401 "error": "Unauthorized or unauthenticated."

If I use - Postman -> Body - > Raw - with the same values - >

{
"authorization": "Bearer APIKEY",
"accept": "application/json" or "application/x-www-form-urlencoded",
"content-type": "application/json"
}

Result - > part of the output : <title>Sign in to your account</title>

I saw somewhere in the articles that NGinx may stripped off some of the headers...not sure if this is relevant here.

@uberbrady - > testing your suggestion in https://jwt.ms/ :

1. aud 1
2. jti - getting unique ID
3. iat - (issued at) - | Wed Mar 17 2021 09:45:16 GMT -- | --
4. nbf - (not before) - | Wed Mar 17 2021 09:45:16 GMT -- | --
5. exp - (expiration time) | Wed Mar 17 2061 09:45:16 GMT -- | --
6. sub - (subject) - 1

I am not sure what else I can test at the moment, as we have this error for the last 2 months. Renewed API keys from several users (admin) - > no result. The same error, either via CURL from Linux OS, or Postman, or from PowerShell module.

Still having doubts about our NGinx part if we need to add additional header setting in the config file for the app as we did for the proxy portion -

proxy_set_header X-Forwarded-Proto $scheme;

Also for some reason due to the fact that we are forcing SAML Login (Azure AD) for our users, obviously the request is hitting Login screen for Azure/Microsoft instead of API directly and then getting the errors above or prompt to login at best.

Let me know what can be done further, so I can test and assist from my side.

Cheers.

jwt.ms: Welcome!

[wq949966]

Hi @snipe / @uberbrady - I think we have something based on the suggestion from @uberbrady !

I used the link to test the JWT token. The expiry date does not look right:

exp | Thu Jan 01 1970 01:00:00 GMT+0100 (Greenwich Mean Time)-- | --

For the demo site token it was correct. But for my token it seems to be 1970!

[newbie-admin]

@snipe @uberbrady

Hi again,

Is it possible to post your NGinx config file or at least the required directives which are handling/allowing Headers. I have test several options to allow all header options to our server hosting the API without success.

Upgraded to the latest from our previous build - v5.0.12 build 5705 --> Version v5.1.4 - build 5886 (master):

git pull
php upgrade.php

After this upgrade I don't see anymore even the "Login" prompt using Postman (Body - Raw) - as described earlier.

Thanks in advance.

[snipe]

The issue seems like it's not necessarily related to the OS of the server, but the OS of the user attempting to make the request, in this case, universally Windows. Which again, is super weird, because we have a lot of Windows users, both as community members and customers, so it's not like it doesn't work universally. Additionally, I don't believe we've had any reports from customers on Windows saying the API isn't working (we host on Ubuntu), so it does lend itself to the argument that it's a server or network config somewhere, as if headers are being dropped or the server is missing some extensions.

What's the output of both of these commands?

composer check-platform-reqs

and

(composer show -t --no-ansi && composer show -s -t --no-ansi) | grep -o "\-\-\(ext-.\+\|php \).\+" | sort | uniq | t -d- -f3-

[wq949966]

Output of Composer check-platform-reqs:

ext-bcmath 7.4.1 success
ext-ctype 7.4.1 success
ext-curl 7.4.1 success
ext-date 7.4.1 success
ext-dom 20031129 success
ext-fileinfo 7.4.1 success
ext-filter 7.4.1 success
ext-gd 7.4.1 success
ext-iconv 7.4.1 success
ext-json 7.4.1 success
ext-ldap 7.4.1 success
ext-libxml 7.4.1 success
ext-mbstring 7.4.1 success
ext-openssl 7.4.1 success
ext-pcre 7.4.1 success
ext-pdo 7.4.1 success
ext-simplexml 7.4.1 success
ext-tokenizer 7.4.1 success
ext-xmlwriter 7.4.1 success
lib-pcre 10.33 success
php 7.4.1 success

[wq949966]

Hi @snipe - The API key seems to have an expiry date of 1970.

[snipe]

The API key seems to have an expiry date of 1970.

That would definitely be a problem then. If you generate a new token and paste that into the jwt decoder, does it say 1970, or something else?

[wq949966]

Hi @snipe - I either get "1970" or "false" in exp field when I try and decode it:

{
"typ": "JWT",
"alg": "RS256"
}.{
"aud": "3",
"jti": "e0b21b4d3073842a63719d9df83c7c2f63ba186f83721f88a2bcc341be26cb180eed423506f447e6",
"iat": 1616096301,
"nbf": 1616096301,
"exp": false,
"sub": "1",
"scopes": []
}.[Signature]

[inietov]

I was looking at this issue and looking at probable causes of errors in JWT and stuff like that, as I'm not able to reproduce this behaviour. Not in Windows, nor Ubuntu, nor Docker (Debian based image). The only thing that I saw causing JWT errors on other products that uses it, is Timezones. have any of you with the error has changed the Timezone in your Snipe-IT configuration?

[wq949966]

Thanks @inietov - Just checked. The time zones are definitely the same.

I just generated an new API token and the exp evaluates to false.

[wq949966]

I explicitly set the TIME ZONE in the .env file to be Europe\London to match the IIS server. Still the new token generated has a epx set to false. Why is teh value for env evaluating as false? Any help with be graciously accepted!

[uberbrady]

The only other thing I'm wondering is if you have an APP_KEY set? I did see a problem with another user where they didn't have one set and strange things happened around doing any kind of cryptography (because the APP_KEY is the actual key that's used to do any simple symmetric encryption/decryption).

[wq949966]

@snipe / @uberbrady - Its fixed!! I checked the API_KEY as suggested by @uberbrady and it seemed fine. What I then did was change the API_TOKEN_EXPIRATION_YEAR to be 1 instead of 40 and it came back to life! Not sure why and the root cause will remain one of life's big mysteries but it works at 1 year and definitely does not at 40 years.

API_TOKEN_EXPIRATION_YEARS=1

[wq949966]

A BIG thanks to @snipe and @uberbrady for persisting with this!

[inietov]

This is really weird, if you put back the 40 in API_TOKEN_EXPIRATION_YEAR it breaks again?
Can @infotronicx, @newbie-admin or any other person affected try this workaround and confirm if this fix for you too?

[uberbrady]

I'm also curious if we can figure out what number of years it 'breaks' at - my guess is somewhere around 16 or 17.
But I'd love to see what happens at 10 years? If that works, then try 15? If it didn't, try 5 - and so on, until we have two years, x and x+1 and it works fine for 'x' and fails at 'x+1'.

I also am wondering if you somehow have a 32-bit PHP variant installed somewhere....hrm....

[infotronicx]

Hi team, I was managed to make API work by putting 1 year instead of 40 in env. It is working now. Confirm the solution. Regards,

…

On Tue, 23 Mar 2021, 3:00 am Ivan Nieto Vivanco, ***@***.***> wrote: This is really weird, if you put back the 40 in API_TOKEN_EXPIRATION_YEAR it breaks again? Can @infotronicx <https://github.com/infotronicx>, @newbie-admin <https://github.com/newbie-admin> or any other person affected try this workaround and confirm if this fix for you too? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9157 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAUECYPCEGO7FI32ICJETLTE6ZJBANCNFSM4X2FL4WQ> .

[snipe]

@infotronicx thanks so much for letting us know - and thanks @uberbrady and @inietov for your sleuthing on this.

I'd be curious to know what the largest number of years we can use in there would be. I can certainly set the default to something lower - I picked 40 kind of at random, but would be willing to drop it to something smaller if it would work more universally.

[JohnnyPicnic]

Just spent a long time trying to figure out my API 401 error before finding this thread. Was able to go up to 15 years before getting unauthorized.
Snipe-IT versionv5.1.5 build 6029 (gb8c356443)Software LicenseAGPL3
PHP Version7.2.9-1+b2Laravel Version6.20.26
Raspbian

[wq949966]

@JohnnyPicnic thanks for the update. Very helpful.

[snipe]

We've been working with the theory that this is related to the Y38 problem, which seems to only - or mostly - affect 32-bit systems, which means that that maximum number will change over the years (if we're right, which we may not be.)

Regardless, it seems like 15 is a safe number to work from for now.