2

What's the minimal length for storing a Facebook API Access token in SQL Server?

sooty
  • 543
  • 1
  • 5
  • 14
  • "Best" in regard to what? Minimum storage? Facebook currently uses OAuth 2, in which access tokens are only defined to be strings, which makes it hard to make any assumptions like nchar vs char, length etc. – bzlm Feb 05 '12 at 10:19
  • my bad, should have said minimal storage. What's the best practise for defining the length? – sooty Feb 05 '12 at 10:28
  • You can edit your questions to provide more info or clarify your question. Click the [edit](http://facebook.stackoverflow.com/posts/9148431/edit) button at the bottom left corner of your question. – Lix Feb 05 '12 at 10:30
  • Hi! I work at Facebook and I can give a definitive answer about this. Please don't put a maximum size on the storage for an access token. We expect that they will both grow and shrink over time as we add and remove data and change how they are encoded. We did give guidance in one place about it being 255 characters. I've updated the blog post that had that information and updated our new access token docs to include a note about sizes: https://developers.facebook.com/docs/facebook-login/access-tokens/ Sorry for the confusion. – Christopher Blizzard May 03 '13 at 19:03

3 Answers3

2

With the way and frequency Facebook likes to break things for developers, the SQL server equivalent of nvarchar(max) is the only safe way.

bkaid
  • 51,465
  • 22
  • 112
  • 128
  • "With the way and frequency Facebook likes to break things for developers..." - **IMO**, Facebook's [90 day breaking change policy](https://developers.facebook.com/roadmap/change-policy/) is enough time to make the required changes. In an ever changing social world we gotta stay on top of things... – Lix Feb 05 '12 at 15:19
  • And the only way to know is to constantly check their blog posts. Plus the 90 day breaking change policy is a joke. Many breaking changes haven't fallen under that. – bkaid Feb 05 '12 at 15:26
  • "constantly check their blog posts" - this is a must! You are developing on a 3rd party platform - its the same for any other 3rd party platform. – Lix Feb 05 '12 at 15:43
  • 1
    Most 3rd party platforms don't hate their developers. Name a 3rd party platform with that many frequent breaking changes and never ending stream of bugs that don't get fixed. – bkaid Feb 05 '12 at 16:14
  • 2
    Name a social platform with the same reach as Facebook ;) I mean no disrespect my friend - and we seem to have entered a debate here... Lets leave it here. We can't dictate how Facebook runs their operation - we do however have a choice on what platforms we develop. – Lix Feb 05 '12 at 16:17
0

EDIT

As the question has changed. I'd suggest you nvarchar(400). This is really too much, but genrally acceptable. As a database developer you always must keep in mind that there can be unpredicted unicode, even when you are absolutely sure that the incoming length will be very small and there will only be English letters.

P.S. domain names always deemed to be only English letters, untill now. http://путин.рф is an example. This is a working domain.

Source: http://en.wikipedia.org/wiki/.%D1%80%D1%84

Oybek
  • 7,016
  • 5
  • 29
  • 49
  • 2
    I think this is a little bit extreme - see @bzim's comment and the [Facebook blog post](https://developers.facebook.com/blog/post/572/) he linked to. Taken from the post - "The new access token format is completely opaque and you should not take any dependency on the format in your code. **A varchar(255) field will be sufficient to store the new tokens**.". – Lix Feb 05 '12 at 13:55
  • 2
    @Lix, this is not extreme. The advice was just have some buffer from all sides just to ensure all cases. [_ ...The storage size is the actual length of data entered + 2 bytes ..._](http://msdn.microsoft.com/en-us/library/ms176089.aspx). Hence it doesn't really waste anyting in case of 400 and nvarchar is also a precautions. – Oybek Feb 05 '12 at 14:14
  • 1
    @Lix, and downvotes must be casted wisely! When the post is _...an egregiously sloppy, no-effort-expended post, or an answer that is clearly and perhaps dangerously incorrect..._ – Oybek Feb 05 '12 at 14:17
  • 1
    downvotes are a very subjective thing. Please don't take offence. Your answer is **not** sloppy, effort **was** made and your answer is **not** incorrect. However I feel, **IMO**, that your answer is not too useful to the OP. Facebook themselves have detailed the requirements of storing the token and therefore making the data type "too big" is unnecessary. Your answer would not have received my downvote if the `facebook` tag was not present in the question, but, it is. Since this is a Facebook specific question, Facebook's recommendations should be adhered to. – Lix Feb 05 '12 at 14:27
  • 1
    Your argument with regard to unicode values is very valid however irrelevant to this question. – Lix Feb 05 '12 at 14:30
0

I guess you want store it in a mysql database.
use 255 varchar field length of database table

you can also check fb full blog post here https://developers.facebook.com/blog/post/572

Danish Iqbal
  • 1,464
  • 1
  • 13
  • 24
  • 1
    [According to Facebook](http://developers.facebook.com/blog/post/572/), 128 won't work. Also see [this question](http://stackoverflow.com/questions/4408945/what-is-the-length-of-the-access-token-in-facebook-oauth2). – bzlm Feb 05 '12 at 13:16
  • @bzlm thanks increasing my knowledge that 128 is not working i update the answer – Danish Iqbal Feb 05 '12 at 14:26
  • This answer is now outdated and no longer correct. Refer to: http://stackoverflow.com/questions/4408945/what-is-the-length-of-the-access-token-in-facebook-oauth2 – Doug S Aug 15 '15 at 02:39