Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with login.json and authentication relay #2327

Closed
pliablepixels opened this issue Nov 29, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@pliablepixels
Copy link
Member

commented Nov 29, 2018

Describe Your Environment

  • Version of ZoneMinder: 1.32.2
  • Built from source do_debian.sh
  • Ubuntu 18

Describe the bug

Users who switched to the new version of zmNinja that uses login.json are complaining streaming breaks. In all cases, it is because they have AUTH_RELAY set to "none". One user told me today it was recommended they set it to "none" to fix some console error (not sure about this)

There is a problem with how login.json works today. The summary is if you use OPT_AUTH and AUTH_HASH_LOGINS but set AUTH_RELAY to none, the credentials return user=username instead of user=username&pass=password or auth=token. This is wrong because streaming breaks.

Suggested solutions:

  • We append password to the authRelay=none situation too here

  • However, I am not sure why we are using authRelay as a check at all. Should we not be simply using AUTH_HASH_LOGINS instead and if so, return &auth= irrespective of what AUTH_RELAY is set to? This API was modeled after the code in userLogin in PHP land but I'm not sure why its this way now.

@knight-of-ni

This comment has been minimized.

Copy link
Member

commented Nov 29, 2018

When streaming only works when AUTH_RELAY is set to none, that means the end user has a time related issue with their configuration. Setting this to none is a workaround that does not fix the underlying problem. While one can find threads in the user forum where someone set this value to none and reported "success", this was never a recommended solution by us. The recommended solution has always been to fix the underlying time issue. They should fix that problem first before doing anything else.

@connortechnology

This comment has been minimized.

Copy link
Member

commented Nov 29, 2018

I think we should remove all these options and just always use auth_hash. There really is no reason not to.

@pliablepixels

This comment has been minimized.

Copy link
Member Author

commented Nov 29, 2018

Ok thanks. There are two points in this issue

  1. Key point: If AUTH_HASH_LOGIN is on, and AUTH_RELAY is set to None, what should login.json return in its credentials? Today it is user=username which seems incorrect to me. In its current form, streaming doesn't work because zms does not get auth passed correctly

  2. Other point: Does ZM recommend auth_relay to none - which you have answered

@pliablepixels

This comment has been minimized.

Copy link
Member Author

commented Nov 29, 2018

Ok, looks like @connortechnology and my posts crossed.

@pliablepixels

This comment has been minimized.

Copy link
Member Author

commented Nov 29, 2018

@connortechnology - I'll take this discussion to slack before I do a PR - have more Qs

knight-of-ni added a commit that referenced this issue Nov 29, 2018

Merge pull request #2328 from pliablepixels/login-auth-relay
returns user=&pass= in credentials for auth_relay plain and none  #2327
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.