Change Details

This is the fix for the follow-up task.

This is the fix for the follow-up task [[ https://linear.app/comm/issue/ENG-621/handle-collision-in-new-sessionid-creation-in-tunnelbroker-without | ENG-621 ]] Context from the task: - At the moment for sessionID creation, we rely on `boost::uuids::random_generator()` which instance creates every gRPC handler request that affects the random generator internal counter. We need to fix this by moving the generator out of the function or not using an internal counter. **Solution:** By default `boost::uuids::random_generator()` uses `mt19937` which is not cryptographically secure. By switching to use `std::random_device` we will produce enough secure results because it uses `/dev/(u)random` and no need to move it outside the function. - When the unique SessionID has a collision with the already existing in the Database we are falling into the error instead of generating a new one. **Solution:** In case we already have a record with the same `sessionID` in the database we generate a new `sessionID` until we have not the record with the same `sessionID` (in case of multiple collisions).

This is the fix for the follow-up tasktask [[ https://linear.app/comm/issue/ENG-621/handle-collision-in-new-sessionid-creation-in-tunnelbroker-without | ENG-621 ]] Context from the task: - At the moment for sessionID creation, we rely on `boost::uuids::random_generator()` which instance creates every gRPC handler request that affects the random generator internal counter. We need to fix this by moving the generator out of the function or not using an internal counter. **Solution:** By default `boost::uuids::random_generator()` uses `mt19937` which is not cryptographically secure. By switching to use `std::random_device` we will produce enough secure results because it uses `/dev/(u)random` and no need to move it outside the function. - When the unique SessionID has a collision with the already existing in the Database we are falling into the error instead of generating a new one. **Solution:** In case we already have a record with the same `sessionID` in the database we generate a new `sessionID` until we have not the record with the same `sessionID` (in case of multiple collisions).