I was hoping to avoid needing str_replace -- but I've been convinced. I'm
happy with base64url :)
Thanks,
-Naitik
On Tue, Jul 6, 2010 at 9:17 PM, Evan Gilbert uid...@google.com wrote:
Hi all - having a little bit of a hard time following the full thread, but
I'm strongly in favor of base64url
Hi all - having a little bit of a hard time following the full thread, but
I'm strongly in favor of base64url encoding.
A big advantage of this encoding is that, if token is base64url encoded,
then urlencode(token) == token.
This allows developers to avoid a large class of problems in dealing
On 2010-07-02, at 5:04 PM, Paul Tarjan wrote:
We don't think base64url will work, because the most common error we'll see
is that developers forget the url part and just do plain base64, and
that's not sufficient because the stock set includes +.
I think forgetting to url-decode is more
On Sat, Jul 3, 2010 at 9:02 AM, Dick Hardt dick.ha...@gmail.com wrote:
On 2010-07-02, at 5:04 PM, Paul Tarjan wrote:
We don't think base64url will work, because the most common error we'll
see is that developers forget the url part and just do plain base64, and
that's not sufficient
Let's not lose sight of the underlying reason to choose base64:
avoiding the issue of canonicalisation. If you use an encoding that
various software layers can choose to decode and operate on, then you
open the canonicalisation can of worms. The point of using base64 is
so the blob you hand around
On 2010-07-03, at 9:13 AM, Naitik Shah wrote:
I think Naitik is saying that accidentally doing base64 and not base64url
will send some '+'s along.
if there are '+'s in the token, then it is easy for someone helping to spot
the problem. also easy for servers to send back an error message
On 2010-07-03, at 11:28 AM, Luke Shepard wrote:
* We'd like the signature first (so you can left split instead of right
split)
What are the advantages of left split vs right split?
Built in split function with a limit is more common, which makes the left
split easier.
Size
On 2010-07-03, at 12:14 PM, Naitik Shah wrote:
On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt dick.ha...@gmail.com wrote:
On 2010-07-03, at 9:13 AM, Naitik Shah wrote:
I think Naitik is saying that accidentally doing base64 and not base64url
will send some '+'s along.
if there are '+'s
We don't think base64url will work, because the most common error we'll see
is that developers forget the url part and just do plain base64, and
that's not sufficient because the stock set includes +.
I think forgetting to url-decode is more likely than doing the wrong base64
encoding.
Searching for base64url does make it better. Thanks for that pointer Dick.
We don't think base64url will work, because the most common error we'll see
is that developers forget the url part and just do plain base64, and
that's not sufficient because the stock set includes +.
So it will maybe
On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard lshep...@facebook.com wrote:
Brian, Dirk - just wondering if you had thoughts here?
The only strong reason I can think of for base64 encoding is that it allows
for a delimiter between the body and the signature. Is there any other reason?
On Fri, Jun 25, 2010 at 11:39 AM, Breno breno.demedei...@gmail.com wrote:
On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard lshep...@facebook.com
wrote:
Brian, Dirk - just wondering if you had thoughts here?
The only strong reason I can think of for base64 encoding is that it
allows for a
There are 2 characters that are different between base64 and base64url.
Many good libraries support both (as they're both useful, and both are in
the base64 RFC spec); the ability to eliminate a class of encoding problems
seems like a good trade-off for, in some languages without full base64
So my litmus test was looking on the web for web base 64 or web base64.
Both yield nothing useful. Looking at the docs for PHP, it doesn't seem to
support it, Python does, Ruby doesn't seem to. Java doesn't seem to have a
native base64, and the C# one doesn't seem to have the web version (a bit
The RFC term is base64url which turns up much better results when searching.
URL safe base64 is also a good search term.
Note that the token may also be included in the HTTP header. base64url encoding
works well for HTTP headers. Note that the token is opaque to the client, so
being plain text
15 matches
Mail list logo
