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

401 errors from taky_dps #92

Open
dceejay opened this issue Sep 14, 2023 · 4 comments
Open

401 errors from taky_dps #92

dceejay opened this issue Sep 14, 2023 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@dceejay
Copy link

dceejay commented Sep 14, 2023

Hi Tim

I'm trying to use Taky 0.9 - and All I get when try to use taky_dps with no ssl is errors like

"GET /Marti/sync/search?keywords=missionpackage&tool=public HTTP/1.1" 401 317 "-"
"GET /Marti/sync/missionquery?hash=7b13f9342048b665008f669dff278d04c5afd107468c09690fbdcfa638bbe453 HTTP/1.1" 401 317 "-"
"GET /Marti/api/clientEndPoints HTTP/1.1" 401 317 "-"
"GET /Marti/api/version/config HTTP/1.1" 200 112 "-"

Only the get version seems to work...
What am I missing ?

the relevant part of taky.conf is

[dp_server]
upload_path = /var/taky/dp-user

[ssl]
enabled = false
client_cert_required = False

In the changelog I see mention of DPS endpoints that don't require client certificates - where are these documented ? How would you set a device to use them if they are on a different path as my device only lets me specify the base server.

@dceejay dceejay changed the title 401 errors 401 errors from taky_dps Sep 14, 2023
@dceejay
Copy link
Author

dceejay commented Sep 14, 2023

I "think" the issue is that there is now authorisation checks all over the place - but no way to turn them off in the config...
I think there should probably be some config check around here

def check_headers(*args, **kwargs):

@tkuester
Copy link
Owner

Hey! Sorry I've been away for so long on this.

I'm trying to think of a way to provide access to this in a bit more of a fine grained way. Would you consider something like an option to allow certain IP addresses (ie: 127.0.0.1) access without providing credentials?

@tkuester tkuester added the enhancement New feature or request label Sep 29, 2023
@dceejay
Copy link
Author

dceejay commented Sep 30, 2023

Sure. But I'd also like to allow ranges eg a local subnet eg 192.168.1.*

@lucasburlingham
Copy link

lucasburlingham commented Mar 18, 2024

I ran into this issue today. I think what needs to be done is that before the headers are checked, it should check to see if SSL is on or not. If it is, fine, check the headers. But if its not (like in my case), don't check the headers because we know none are to be had.

Once I get the time I'll see what I can do - this seems like it would be a simple (enough) fix given time and focus.

EDIT: I found the time, and is quite rewarding considering I need to be able to sync files from EUD's this week to save face at work, but yet another reason to use OSS. Please find my fixes in #94. For the meantime, my fork is located at thebarracksarmy/taky and I'll keep it abreast of changes here until this issue gets fixed.

lucasburlingham added a commit to thebarracksarmy/taky that referenced this issue Mar 18, 2024
lucasburlingham added a commit to thebarracksarmy/taky that referenced this issue Mar 18, 2024
tkuester added a commit that referenced this issue Apr 5, 2024
tkuester added a commit that referenced this issue Apr 5, 2024
tkuester added a commit that referenced this issue Apr 5, 2024
@tkuester tkuester self-assigned this Apr 5, 2024
@tkuester tkuester added bug Something isn't working and removed enhancement New feature or request labels Apr 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants