Closed rugk closed 8 months ago
Also what is that about the (wrong?) number being prefilled there?
Ohh... I get what you mean. My tokens all start with 1079-
and the travelynx API docs suggested to use a token starting with 1079-
so I thought, all tokens start with 1079-
This is of course confusing and I'll remove it with the next release.
Just add a text stating which key to use.
I don't know if we need a further description which token to use, because the text field is called "travelynx travel token" which implies that you should use the token next to "travel".
because the text field is called "travelynx travel token"
Oh gosh, TBH, I did not bother to read the smallest text on that screen (also it reads "travelynx Travel-Token", if you skim that text, you are likely to miss out of the middle part IMHO; similar like this for characters in a word) and initially just wondered when you pointed me there, "wait… this is there?". I guess this hints this is an UX issue.
If travelyx would have a page to only serve one token, you could maybe link to that/open it or so, but without that hmm…
and the travelynx API docs suggested to use a token starting with 1079- so I thought, all tokens start with 1079-
Hmm, maybe that has just changed?
It seems, like for me, all tokens nowadays start with 2341
. (So maybe you can just change the prefix?)
https://travelynx.de/api
After all having a prefix is good for token scanning and maybe they did it, because of that.
(I mean it would have been useful for us to make Travelynx start the travel token with something different than the others, etc. This could ease the confusion and simply allow to check whether the token is the correct one.)
Opened https://github.com/derf/travelynx/issues/124 to clarify this at the Travelynx side/see what they can do.
apperently you have never come across uuids.
the particulare type of uuid that is generated here is a type 4 uuid (which is the default output of uuidgen
(and generally recommended as the type to use database primary key column these days). you can see its a type 4 uuid because their pattern is XXXXXXXX-XXXX-4XXX-XXXX-XXXXXXXXXXXX
(anything but the 4
and -
is random hex (the entire point of type 4 is being random) so you won't get anywhere expecting a known prefix.
I'm being told (verbally so its probably spelled differently) kotlins uuid class has a tryparse function you can use to validate a string being a uuid
I have just found out that the first part of the travelynx API token is your own travelynx ID (uid). The prefix is different for everyone and the whole token is not even the same length for everyone. For example, the first part of my API token is only a 3-digit number. So you have to keep this in mind in case you want to implement input validation in any form.
Ohh... I get what you mean. My tokens all start with
1079-
and the travelynx API docs suggested to use a token starting with1079-
so I thought, all tokens start with1079-
It seems, like for me, all tokens nowadays start with 2341. (So maybe you can just change the prefix?) https://travelynx.de/api
If you are logged in and open the travelynx API docs page, all available data (uid and token - if generated) will be added to your docs page. That's why @jheubuch sees "1079-" and @rugk sees "2341-".
Ah thanks, that makes sense. Whether it is a uuid or not is then hardly relevant, given it is just a string for the client/API key consumer.
Is your feature request related to a problem? Please describe. The app prompts/allows me to add an API key:
Now I need to manually go to the Travelyx website, find the API settings, generate and copy the API key and paste it. For me being technical, this is not a real problem, but it is cumbersome.
Anyway, actually, I have a bigger problem: I am presented with these API keys on the website?
The issues:
Describe the solution you'd like
Describe alternatives you've considered A login workflow like for Traewelling would of course be best.
Additional context
114