Seems like new_client may overwrite the req_id with a generated value, if the id already is in use by another client.
This causes an inconsistency between id and url. This is just a quick fix to make it consistent.
I suspect a proper fix would be some sort of secret_token returned the client that reserves the id. So that other clients can't use it. But that might be overkill, keeping the service simple seems like a good choice :)
Seems like `new_client` may overwrite the `req_id` with a generated value, if the `id` already is in use by another client.
This causes an inconsistency between id and url. This is just a quick fix to make it consistent.
I suspect a proper fix would be some sort of `secret_token` returned the client that reserves the `id`. So that other clients can't use it. But that might be overkill, keeping the service simple seems like a good choice :)
The fix here is to actually return the url that corresponds to the id assigned to the client (in the case where they requested an id which was not available?)
The fix here is to actually return the url that corresponds to the id assigned to the client (in the case where they requested an id which was not available?)
The fix here is to actually return the url that corresponds to the id
assigned to the client (in the case where they requested an id which was
not available?)
Yeah, that what this PR does...
It returns the randomly generated id, if the id requested is in use...
Den 18. mar. 2017 5.23 PM skrev "Roman Shtylman" <[email protected]>:
> The fix here is to actually return the url that corresponds to the id
> assigned to the client (in the case where they requested an id which was
> not available?)
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/localtunnel/server/pull/59#issuecomment-287585031>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAJI5BZdFOfqF7f6Zl5dQRjfiY93WS6mks5rnHV_gaJpZM4Mhj8F>
> .
>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Seems like
new_clientmay overwrite thereq_idwith a generated value, if theidalready is in use by another client.This causes an inconsistency between id and url. This is just a quick fix to make it consistent.
I suspect a proper fix would be some sort of
secret_tokenreturned the client that reserves theid. So that other clients can't use it. But that might be overkill, keeping the service simple seems like a good choice :)The fix here is to actually return the url that corresponds to the id assigned to the client (in the case where they requested an id which was not available?)
Yeah, that what this PR does...
It returns the randomly generated id, if the id requested is in use...
Den 18. mar. 2017 5.23 PM skrev "Roman Shtylman" [email protected]: