search

partkeepr / PartKeepr

Open Source Inventory Management
http://www.partkeepr.org
GNU General Public License v3.0
1.38k stars 400 forks source link

The server returned a response which we were not able to interpret (partkeepr-1.1.0) #748

Closed WeisTekEng closed 3 years ago

WeisTekEng commented 7 years ago

Setup partkeepr in a virtual machine on a freenas server, per the wiki. I can access the server on my network with other computers but any action brings up the critical error window.

Here is the (full report tab) contents. This happens while trying to add parts, distributors etc.

Critical Error

Details

The server returned a response which we were not able to interpret.

Request

GET http://192.168.137.127:8080/api/system_notices?_dc=1480104197709

Response Status Code

401

Response

Server Configuration

doctrine_orm_version: 2.5.4 doctrine_dbal_version: 2.5.2 doctrine_common_version: 2.6.0-DEV php_version: 7.0.13-1~dotdeb+8.1 auto_start_session: true maxUploadSize: 2097152 availableImageFormats: JPG,GIF,PNG max_users: unlimited authentication_provider: PartKeepr.Auth.WSSEAuthenticationProvider tip_of_the_day_uri: https://partkeepr.org/tips/%s password_change: true

watersAbove commented 7 years ago

The clock on your VM must be precisely sync'd to your system clock. The WSSE auth scheme has very little wiggle room for mismatched times, which causes loads of issues in the real world, even with time servers on.

WeisTekEng commented 7 years ago

OK, bios clock right. I'll give that a look.

Thanks I'll let you know what happens.

On Fri, Nov 25, 2016, 2:54 PM brads4 notifications@github.com wrote:

The clock on your VM must be precisely sync'd to your system clock. The WSSE auth scheme has very little wiggle room for mismatched clocks, which causes loads of issues in the real world, even with time servers on.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/partkeepr/PartKeepr/issues/748#issuecomment-263030302, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ0MLBxt5RjVquD0YJ_O3YGIFrXQZS8Mks5rB2cIgaJpZM4K8sJm .

WeisTekEng commented 7 years ago

That now all matches, still doing the same thing when i click on anything. eg add distributor. running apache2.2 do i need to upgrade to 2.4?

WeisTekEng commented 7 years ago

Ran setup again, chose HTTP auth and it works great so far. its on an internal network within another internal network anyway so I'm not worried about any one messing with it.

Thanks.

watersAbove commented 7 years ago

The WSSEAuth in this program is tricky. I had a LOT of issues when working with it.

Issues I have had:

To assist speeding up my app, I use NGINX, which helps a lot.

WeisTekEng commented 7 years ago

Thabks for the help and information. Ya? You like it better than apache? I've never tried nginx, maybe in roll a jail and see what it's like.

On Fri, Nov 25, 2016, 4:17 PM brads4 notifications@github.com wrote:

The WSSEAuth in this program is tricky. I had a LOT of issues when working with it.

Issues I have had:

  • total system lockout due to clocks being out of sync (before I knew what was going on)
  • issues with web services failing due to response body sizes (this issue presents in the web layer as well)
  • it seems basically, WSSE auth was never tested in real world situations, as a local dev environment would never present these types of bugs.

To assist speeding up my app, I use NGINX, which helps a lot.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/partkeepr/PartKeepr/issues/748#issuecomment-263034786, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ0MLIvxvepODjfUOT_6ChypY71T2S0Wks5rB3qSgaJpZM4K8sJm .

watersAbove commented 7 years ago

It's super fast. I'm not a super expert on web tech of this type, but I know a lot of people use it as a caching proxy in front of apache, as well as standalone. I chose standalone, because I wanted fast and simple. Partkeepr doesn't require any major complex server config, so I thought I'd try it out. It's quite easy to deploy, and noticeably faster than apache. I believe it uses non blocking IO and disposes of the thread/process per request model, in favor of reusable handlers, making scaling much much easier.

WeisTekEng commented 7 years ago

Mmm I'll definitely have to try it out.

On Fri, Nov 25, 2016, 4:26 PM brads4 notifications@github.com wrote:

It's super fast. I'm not a super expert on web tech of this type, but I know a lot of people use it as a caching proxy in front of apache, as well as standalone. I chose standalone, because I wanted fast and simple. Partkeepr doesn't require any major complex server config, so I thought I'd try it out. It's quite easy to deploy, and noticeably faster than apache. I believe it uses non blocking IO and disposes of the thread/process per request model, in favor of reusable handlers, making scaling much much easier.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/partkeepr/PartKeepr/issues/748#issuecomment-263035136, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ0MLGGotzw87Idk1zAQhjTfA1PL5GCaks5rB3ypgaJpZM4K8sJm .

watersAbove commented 7 years ago

It suites the actual real world conditions of today's internet, full of cyber attacks and greedy clients consuming indiscriminently. it's gaining market share fast, and is already an industry standard as a fast caching solution for apache.

robindegen commented 7 years ago

I'm also getting this error quite a lot on my setup.

cach9 commented 6 years ago

I have the same problem. can anybody help me. The error does not stop coming. Try nginx without apache and follow the problem.

GET http://inventario:8080/api/system_notices?_dc=1519155396693

Critical Error

Details

The server returned a response which we were not able to interpret.

Request

GET http://inventario:8080/api/system_notices?_dc=1519155396693

Response Status Code

0

Response

Server Configuration

doctrine_orm_version: 2.5.4 doctrine_dbal_version: 2.5.2 doctrine_common_version: 2.6.0-DEV php_version: 7.0.27-0+deb9u1 auto_start_session: true maxUploadSize: 2097152 isOctoPartAvailable: false availableImageFormats: JPG,GIF,PNG max_users: unlimited authentication_provider: PartKeepr.Auth.HTTPBasicAuthenticationProvider tip_of_the_day_uri: https://partkeepr.org/tips/%s password_change: true patreonStatus: [object Object]

justintconroy commented 6 years ago

I'm getting the same error right now

Critical Error

Details
==================================
The server returned a response which we were not able to interpret.

Request
==================================
GET http://partkeepr.conroy.in/api/system_notices?_dc=1520172355763

Response Status Code
==================================
0

Response
==================================

Server Configuration
==================================
doctrine_orm_version: 2.5.4
doctrine_dbal_version: 2.5.2
doctrine_common_version: 2.6.0-DEV
php_version: 7.0.25-0ubuntu0.16.04.1
auto_start_session: true
maxUploadSize: 2097152
isOctoPartAvailable: false
availableImageFormats: JPG,GIF,PNG
max_users: unlimited
authentication_provider: PartKeepr.Auth.WSSEAuthenticationProvider
tip_of_the_day_uri: https://partkeepr.org/tips/%s
password_change: true
patreonStatus: [object Object]

I'm also sometimes getting a 401 response on requests to storage_locations. If I see that one again, I'll also post that error log.

Drachenkaetzchen commented 6 years ago

@justintconroy as pointed out earlier in the thread, use HTTP Basic instead of WSSE.

Drachenkaetzchen commented 6 years ago

To process this issue further, I need an excerpt of the app/logs/partkeepr.log file to see what happens at the exact time when the error in the frontend occurs. Please do NOT post the whole file, just the errors which are logged when the problem occurs.

robindegen commented 6 years ago

Since the latest update I haven't received this error anymore, at least I haven't seen it yet

christianlupus commented 4 years ago

As WSSE is deprecated and shall be replaced by HTTP Basic in the future, I am closing this here as oout-of-date.

SooshiPaw commented 3 years ago

I am still receiving this error message after changing from WSSE to HTTP Basic.


Details
==================================
The server returned a response which we were not able to interpret.

Request
==================================
GET http://NNNNNNNN/api/system_notices?_dc=1611052100222

Response Status Code
==================================
0

Response
==================================

Server Configuration
==================================
doctrine_orm_version: 2.5.4
doctrine_dbal_version: 2.5.2
doctrine_common_version: 2.5.3
php_version: 7.1.33-25+0~20210112.45+debian9~1.gbp1a89bf
auto_start_session: true
maxUploadSize: 2097152
isOctoPartAvailable: false
availableImageFormats: JPG,GIF,PNG
max_users: unlimited
authentication_provider: PartKeepr.Auth.HTTPBasicAuthenticationProvider
tip_of_the_day_uri: https://partkeepr.org/tips/%s
password_change: true
patreonStatus: 
defaultGridPresets: []

The only error message in partkeepr.log is:

[2021-01-19 09:07:03] app.WARNING: Bad credentials. [] []

This happens on all computers using the system; FireFox and Chrome.

I am using git master branch checked out on Nov 5th 2020

I cleared the cache following the auth provider configuration change, but may have missed additional required steps?

Edit to add: Curiosly the apache access log shows the request as successful (status 200), and logs the authenticated username

192.168.11.159 - MYUSERNAME [19/Jan/2021:13:13:48 +0100] "GET /api/system_notices?_dc=1611058428979&page=1&start=0&itemsPerPage=99999999 HTTP/1.1" 200 953 "http://NNNNNNNNNN/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0"

Manually fetching the same URI from the browser also works without issues:

{"@context":"\/api\/contexts\/SystemNotice","@id":"\/api\/system_notices?_dc=1611058428979\u0026page=1\u0026start=0\u0026itemsPerPage=99999999","@type":"hydra:PagedCollection","hydra:totalItems":0,"hydra:itemsPerPage":99999999,"hydra:firstPage":"\/api\/system_notices?_dc=1611058428979\u0026start=0\u0026itemsPerPage=99999999","hydra:lastPage":"\/api\/system_notices?_dc=1611058428979\u0026start=0\u0026itemsPerPage=99999999","hydra:member":[],"hydra:search":{"@type":"hydra:IriTemplate","hydra:template":"\/api\/system_notices{?}","hydra:variableRepresentation":"BasicRepresentation","hydra:mapping":[]}}

christianlupus commented 3 years ago

OK, I will reopen this issue again.

christianlupus commented 3 years ago

@kivyhax Just to make sure it is not just a trivial issue: The username and password are correct and set correctly (the same in the database as the ones you try to log in as)?

SooshiPaw commented 3 years ago

@christianlupus as far as I am aware there are no issues with the passwords, though perhaps I am not catching your exact question? This issue occurs for all users on my installation. Logging in works fine, the error pops up "randomly", both in idle and active sessions. If I log in and leave the computer for an hour, I will return to find the above message. If I stay active, it will appear randomly and need to be closed to continue working.

SooshiPaw commented 3 years ago

@christianlupus I have discovered a network issue at client site that appears to be the cause of this PartKeepr error message, likely this bug is already resolved in your end.

The client's network straight up dies for a few seconds on (ir)regular intervals. My current theory is that the error message occurs if PartKeepr javascript makes the request while the network is down, which explains why there are lots of successful requests logged by the webserver, and the http 0 response code reported by PartKeepr.

christianlupus commented 3 years ago

That sounds feasible. I will reclose then here.