• r

    rp

    2 years ago
    The reason why the demo works only for Mozilla is because copying cookies to emulate an attacker is simplest on Mozilla. On chrome and other browsers, you can’t see the refresh token cookie unless you load the refresh token path in the URL. Which for demo purposes is difficult to communicate. There is no inherent limitation and the solution works the same on all browsers.
  • r

    rp

    2 years ago
    @Everybody apologies for deleting your post. I thought it was a bot post. Oops! 😅
  • r

    rp

    2 years ago
    Also, @tredstone, get is an optional parameter which is undefined by default. So, if you don’t pass it, the signing key is generated and maintained by the library
  • Everybody

    Everybody

    2 years ago
    I'm attempting to work out a solution to hosting a public facing encrypted database on .git which tiers access to users DHT web torrent style multi-client solutions under consideration.
  • r

    rp

    2 years ago
    @Everybody I see. I’m not too sure I completely understand what you mean, but I’m happy to help out if you have any specific question 🙂
  • tredstone

    tredstone

    2 years ago
    is there a reason the accessToken and refreshTokens are attaches to the response as cookies?
  • tredstone

    tredstone

    2 years ago
    as opposed to sending them in the response body and attaching the access token as an Authorization header
  • tredstone

    tredstone

    2 years ago
    with the current implementation, aren't the access token and refresh token sent with every request?
  • r

    rp

    2 years ago
    So the recommended way to store the two tokens is via cookies (as opposed to local storage) as it provides security against XSS attacks.
  • r

    rp

    2 years ago
    The refresh token’s cookie path is only specific to your refresh token API