This repository has been archived by the owner on Dec 18, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 51
createToken.py: Fix typo output_filename => input_filename #661
Merged
+17
−8
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no objection to the bug correction itself, the code looks nice and great that you found and addressed it @landgraf.
But both the old and new implementation does not match the example tokens that we actually have in this repository. Like we have
single-read.json
andsingle-read.json.token
, i.e. it seems that.token
has been added and.json
has not been removed. I sort of would prefer that this script matches the example tokens we have, i.e. either just add.token
regardless of whether input issingle-read.json
orsingle-read
, or change name of the example token. The latter would how ever require changes in all places currently using the tokens.So maybe best to just have only
output_filename = input_filename + ".token"
i.e. do not care if input file ends with
.json
or not. The reason why I prefer this option rather than renaming the tokens is that the tokens in this directory are used by KUKSA Server (C++ only, i.e. not Databroker), and we currently do not want to spend too much effort on KUKSA.val ServerThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@erikbosch
I'm not sure If I got your comment.
Current code with suggested change works exactly like you've mentioned.
.json suffix deleted if exists and .token suffix added for all tokens
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've modified code a bit to make it even simpler and clever. Please re-review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but if you look at current files we have for example:
i.e. for existing tokens we did not remove the
.json
suffix when generating tokens, the input is calledsingle-read.json
and the token is calledsingle-read.json.token
, but that is not consistent with a script that generates asingle-read.token
if it getssingle-read.json
as input.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not how current code works.
Prior the change:
If file ends with ".json" then ".json" suffix is dropped and output_filename will be ".token" (without json).
In other words suggested change doesn't change behavior of the positive branch but fixes negative (else) branch which was broken before..
^ This code is broken and fails with:
NameError: name 'output_filename' is not defined
So either your example was not generated with the current version of the script or there's bug somewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I share your conclusion, the current example token pairs in the repository that all have the form
<something>.json
and<something>.json.token
does not match how the script work. If you use<something>.json
as input you get<something>.token
as output. Which gives us three options:.json
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not correct.
All the access tokens in the top level
jwt
folder are named like this (created using this script). They all use the new authorization scopes, and have been placed there in order to not be confused with the legacy tokens found here.Would it help (cause less confusion) to move this script as well to that folder?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad, I only thought about the folder https://github.com/eclipse/kuksa.val/tree/master/kuksa_certificates/jwt, not that https://github.com/eclipse/kuksa.val/tree/master/jwt also use this script.
Yes, we could move the script, but if so we need update *.md files referencing the script. But I think that we anyhow would benefit from having a small
README.md
in this folder that explains how to regenerate the tokens if needed, which will be need if anyone want to use them after 2025-12-31.As I propose a small README I can create a separate PR myself, as this PR itself does not change behavior for input files names
<something>.json
anyway.