Auth Token handling seems to be not case-insensitive

[mhei]

Environment:

• EVerest 2024.2.0 running on a single port charger
• OCPP backend SteVe
• DummyTokenProvider configured which provides the token "DEADBEEF" (upper-case)

Test Sequence:

1. charger is online, connected via OCPP
2. in SteVe, the token is configured using lower-case letters
3. a normal charging session can be started successfully
4. terminate the charging session normally
5. install a reservation via SteVe for the socket, using the "DEADBEEF" token
6. try to start the session

Expected Behavior:

• reservation is recognized and the token is allowed to start the session
• reason: auth tokens in OCPP should be handled case-insenstive

Observed Behavior:

• reservation is recognized but the token is rejected

Trace (stripped down to relevant parts IMHO):

Feb 28 13:30:29 ccc300 manager[2007]: 2024-02-28 13:30:29.356093 [INFO] auth:Auth        :: Received new token: {
Feb 28 13:30:29 ccc300 manager[2007]:     "authorization_type": "RFID",
Feb 28 13:30:29 ccc300 manager[2007]:     "id_token": "DEADBEEF"
Feb 28 13:30:29 ccc300 manager[2007]: }

Feb 28 13:30:29 ccc300 manager[2007]: 2024-02-28 13:30:29.515186 [INFO] auth:Auth        :: Connector is reserved but token is not valid for this reservation
Feb 28 13:30:29 ccc300 manager[2007]: 2024-02-28 13:30:29.605651 [INFO] auth:Auth        :: Result for token: DEADBEEF: REJECTED

Additional note:

• We observed a similar behavior when using LocalAuthList feature of OCPP (i.e. a lower-case token is stored in the list, but then the token provider shows a upper-case one) - so it might be worth to double-check those places of the token handling, too.
• When changing the token in SteVe between step 5 and 6 to lower-case, then the reservation is recognized and the token is accepted, the charging starts.

[golovasteek]

Should we treat all the tokens in Everest in a Case-Insensitive way? Or the objects that emit tokes should normalize them to upper?

[mhei]

From our experience, the tokens coming from a backend via OCPP should be handled as-is interally, e.g. stored unchanged and provided back to the backend in the same way as originally received from the backend. So yes in my eyes, the EVerest internal handling should be case-insensitive. I'm unsure whether a normalization by token publishers is really necessary, and I wonder whether this would actually hurt...

[golovasteek]

Doesn't OCPP explicitly says that token is case-insensitive? I.e. from the protocol perspective the tokens in lower and upper case should be considered the same?

What if the next protocol Everest will support works with case-sensitive tokens?

[lategoodbye]

Doesn't OCPP explicitly says that token is case-insensitive? I.e. from the protocol perspective the tokens in lower and upper case should be considered the same?

What if the next protocol Everest will support works with case-sensitive tokens?

Yes, that's why we cannot normalize it on the token provider side. The token validators must be fixed.

[golovasteek]

The described issue as far as I can see is not in the validator, it is in the Auth module, that compares tokens from OCPP and the from the token provider.

[lategoodbye]

For now i don't have a real insight into the EVerest code. So i consider most of them as black boxes.

[rohansaibuddhi]

Hey, this is unrelated, but which charging protocol is being used in EVerest? Is it OCPP or ISO15118? I am looking at the schema for ISO15118 v2 and v20 and do not see any similarities with the messages being trasmitted by everest(messages obtained from MQTT explorer while running everest on Linux machine) Any help would be appreciated!

[lategoodbye]

@rohansaibuddhi Please don't hijack this bug report and look at the official documentation

In case your questions have not been answered, please use the Zulip