[{"data":1,"prerenderedAt":426},["ShallowReactive",2],{"footer-primary":3,"footer-secondary":93,"footer-description":119,"authentication-ave-what-is-access-control":121,"authentication-ave-what-is-access-control-next":160,"sales-reps":174},{"items":4},[5,29,49,69],{"id":6,"title":7,"url":8,"page":8,"children":9},"522e608a-77b0-4333-820d-d4f44be2ade1","Solutions",null,[10,15,20,25],{"id":11,"title":12,"url":8,"page":13},"fcafe85a-a798-4710-9e7a-776fe413aae5","Headless CMS",{"permalink":14},"/solutions/headless-cms",{"id":16,"title":17,"url":8,"page":18},"79972923-93cf-4777-9e32-5c9b0315fc10","Backend-as-a-Service",{"permalink":19},"/solutions/backend-as-a-service",{"id":21,"title":22,"url":8,"page":23},"0fa8d0c1-7b64-4f6f-939d-d7fdb99fc407","Product Information",{"permalink":24},"/solutions/product-information-management",{"id":26,"title":27,"url":28,"page":8},"63946d54-6052-4780-8ff4-91f5a9931dcc","100+ Things to Build","https://directus.io/blog/100-tools-apps-and-platforms-you-can-build-with-directus",{"id":30,"title":31,"url":8,"page":8,"children":32},"8ab4f9b1-f3e2-44d6-919b-011d91fe072f","Resources",[33,37,41,45],{"id":34,"title":35,"url":36,"page":8},"f951fb84-8777-4b84-9e91-996fe9d25483","Documentation","https://docs.directus.io",{"id":38,"title":39,"url":40,"page":8},"366febc7-a538-4c08-a326-e6204957f1e3","Guides","https://docs.directus.io/guides/",{"id":42,"title":43,"url":44,"page":8},"aeb9128e-1c5f-417f-863c-2449416433cd","Community","https://directus.chat",{"id":46,"title":47,"url":48,"page":8},"da1c2ed8-0a77-49b0-a903-49c56cb07de5","Release Notes","https://github.com/directus/directus/releases",{"id":50,"title":51,"url":8,"page":8,"children":52},"d61fae8c-7502-494a-822f-19ecff3d0256","Support",[53,57,61,65],{"id":54,"title":55,"url":56,"page":8},"8c43c781-7ebd-475f-a931-747e293c0a88","Issue Tracker","https://github.com/directus/directus/issues",{"id":58,"title":59,"url":60,"page":8},"d77bb78e-cf7b-4e01-932a-514414ba49d3","Feature Requests","https://github.com/directus/directus/discussions?discussions_q=is:open+sort:top",{"id":62,"title":63,"url":64,"page":8},"4346be2b-2c53-476e-b53b-becacec626a6","Community Chat","https://discord.com/channels/725371605378924594/741317677397704757",{"id":66,"title":67,"url":68,"page":8},"26c115d2-49f7-4edc-935e-d37d427fb89d","Cloud Dashboard","https://directus.cloud",{"id":70,"title":71,"url":8,"page":8,"children":72},"49141403-4f20-44ac-8453-25ace1265812","Organization",[73,78,84,88],{"id":74,"title":75,"url":76,"page":77},"1f36ea92-8a5e-47c8-914c-9822a8b9538a","About","/about",{"permalink":76},{"id":79,"title":80,"url":81,"page":82},"b84bf525-5471-4b14-a93c-225f6c386005","Careers","#",{"permalink":83},"/careers",{"id":85,"title":86,"url":87,"page":8},"86aabc3a-433d-434b-9efa-ad1d34be0a34","Brand Assets","https://drive.google.com/drive/folders/1lBOTba4RaA5ikqOn8Ewo4RYzD0XcymG9?usp=sharing",{"id":89,"title":90,"url":8,"page":91},"8d2fa1e3-198e-4405-81e1-2ceb858bc237","Contact",{"permalink":92},"/contact",{"items":94},[95,101,107,113],{"id":96,"title":97,"url":8,"page":98,"children":100},"8a1b7bfa-429d-4ffc-a650-2a5fdcf356da","Cloud Policies",{"permalink":99},"/cloud-policies",[],{"id":102,"title":103,"url":81,"page":104,"children":106},"bea848ef-828f-4306-8017-6b00ec5d4a0c","License",{"permalink":105},"/bsl",[],{"id":108,"title":109,"url":81,"page":110,"children":112},"4e914f47-4bee-42b7-b445-3119ee4196ef","Terms",{"permalink":111},"/terms",[],{"id":114,"title":115,"url":81,"page":116,"children":118},"ea69eda6-d317-4981-8421-fcabb1826bfd","Privacy",{"permalink":117},"/privacy",[],{"description":120},"\u003Cp>A composable backend to build your Headless CMS, BaaS, and more. \u003C/p>",{"id":122,"slug":123,"vimeo_id":124,"description":125,"tile":126,"length":127,"resources":8,"people":8,"episode_number":128,"published":129,"title":130,"video_transcript_html":131,"video_transcript_text":132,"content":8,"status":133,"episode_people":134,"recommendations":146,"season":147,"seo":159},"707a5d2a-1db7-4b64-a371-cb332d72b16f","what-is-access-control","1048670023","It's not just enough to give someone access, but sometimes you need to say what they can do. In this stroll down Authentication Avenue, Kevin answers \"What is access control?\"","f02244b4-07b6-413d-b32c-941ca188cc79",6,2,"2025-01-21","What is access control?","\u003Cp>Speaker 0: Hey, developers. And welcome to authentication Avenue. Today, we're going to explore access control. How systems decide what different users can and can't do. It's like having a clever set of rules that keep everything organized and secure.\u003C/p>\u003Cp>Imagine you're at a huge museum. When you enter, everyone gets a different colored badge. Red badges are for the curators who can do everything. Blue badges are for the tour guides who can enter public areas. Green badges are for the cleaning staff who can access maintenance areas.\u003C/p>\u003Cp>And yellow badges are for visitors who can only view exhibits. But it gets even more specific because each badge has special symbols that show exactly what you can do. For example, looking at exhibits, that is the read permission. Creating new displays, that's the create permission. Rearranging exhibits, that's the update permission.\u003C/p>\u003Cp>And finally, removing displays, that's the delete permission. And here's where it gets interesting. Some staff members might only be allowed to change exhibits that they created themselves. Like a junior curator who can only modify their own displays, but not anyone else's. In the tech world, we call this ownership based access.\u003C/p>\u003Cp>Now in Directus, this system is handled through roles, permissions, and policies. Roles are like your colored badges, the broad category you belong to. Permissions are a single rule. For example, what collections you can access or what CRUD operations, that's create, read, update, and delete operations, you can perform. Custom permissions like only view published articles and whether you can only work with items you created, and policies are bundles of permissions that can be applied to either roles or individual users.\u003C/p>\u003Cp>Think of them as rule packages. For example, a content editor role might have policies that allow them to read all articles, create new articles, but only update their own articles, and a content editor might never delete anything or not have the permissions to delete anything. What's cool about policies is their flexibility. You can create one policy, like basic content management, and apply it to both the junior editor role and specific users who need those permissions. It's like creating a standardized set of rules once and then using them wherever you need them.\u003C/p>\u003Cp>So, remember, access control isn't just about yes or no, it's about who can do what, where, and under what conditions. Next up, we'll see how to configure these permissions in Directus. Here we have a posts collection with a field denoting the author. This is a many to one relationship with the director's users collection, and what this means is that each one of these represents a user in our project that could authenticate with this project. So here we see this one is authored by Beth, 2 by me, and 1 by Carmen.\u003C/p>\u003Cp>Now we have an access policy here, which denotes how users can interact with the posts collection. Now remember, the public do not have access to this collection. Instead, we say that users who have this policy applied to them can partially read. We say that they can only read items where they are the author, and we do that using this dynamic variable here called current user, and the value of this will change depending on the currently authenticated user. Exactly the same with update and the same with delete.\u003C/p>\u003Cp>This policy is attached to the member role, which in turn is assigned to Beth, Carmen, and Mike. My user is an admin. So let's see how this works in practice. So here we see we are trying to access the posts collection with no authentication, and we hit send. And as expected, we get a 403 error, which means forbidden, you don't have access to this, or it does not exist.\u003C/p>\u003Cp>As an admin, if I put in an admin token here, we see that we can access all posts. We see there is an author here beginning with 18b and an author here beginning with be8, and that is because admins have full CRUD access, create, read, update, and delete over all collections in the project. This is the exact same request, but with Beth's token, and we see here that if we hit send, we now only get one item returned. In turn, Beth can only update this item or delete this item, but not those created by other users. This is really nice because it means access control is set up and controlled by directus, which means you cannot inadvertently access data that you're not allowed to in your own application because it's all handled at a direct us level.\u003C/p>\u003Cp>So that's just a quick example of how access control works inside of Directus. I will see you next time on Authentication Avenue.\u003C/p>","Hey, developers. And welcome to authentication Avenue. Today, we're going to explore access control. How systems decide what different users can and can't do. It's like having a clever set of rules that keep everything organized and secure. Imagine you're at a huge museum. When you enter, everyone gets a different colored badge. Red badges are for the curators who can do everything. Blue badges are for the tour guides who can enter public areas. Green badges are for the cleaning staff who can access maintenance areas. And yellow badges are for visitors who can only view exhibits. But it gets even more specific because each badge has special symbols that show exactly what you can do. For example, looking at exhibits, that is the read permission. Creating new displays, that's the create permission. Rearranging exhibits, that's the update permission. And finally, removing displays, that's the delete permission. And here's where it gets interesting. Some staff members might only be allowed to change exhibits that they created themselves. Like a junior curator who can only modify their own displays, but not anyone else's. In the tech world, we call this ownership based access. Now in Directus, this system is handled through roles, permissions, and policies. Roles are like your colored badges, the broad category you belong to. Permissions are a single rule. For example, what collections you can access or what CRUD operations, that's create, read, update, and delete operations, you can perform. Custom permissions like only view published articles and whether you can only work with items you created, and policies are bundles of permissions that can be applied to either roles or individual users. Think of them as rule packages. For example, a content editor role might have policies that allow them to read all articles, create new articles, but only update their own articles, and a content editor might never delete anything or not have the permissions to delete anything. What's cool about policies is their flexibility. You can create one policy, like basic content management, and apply it to both the junior editor role and specific users who need those permissions. It's like creating a standardized set of rules once and then using them wherever you need them. So, remember, access control isn't just about yes or no, it's about who can do what, where, and under what conditions. Next up, we'll see how to configure these permissions in Directus. Here we have a posts collection with a field denoting the author. This is a many to one relationship with the director's users collection, and what this means is that each one of these represents a user in our project that could authenticate with this project. So here we see this one is authored by Beth, 2 by me, and 1 by Carmen. Now we have an access policy here, which denotes how users can interact with the posts collection. Now remember, the public do not have access to this collection. Instead, we say that users who have this policy applied to them can partially read. We say that they can only read items where they are the author, and we do that using this dynamic variable here called current user, and the value of this will change depending on the currently authenticated user. Exactly the same with update and the same with delete. This policy is attached to the member role, which in turn is assigned to Beth, Carmen, and Mike. My user is an admin. So let's see how this works in practice. So here we see we are trying to access the posts collection with no authentication, and we hit send. And as expected, we get a 403 error, which means forbidden, you don't have access to this, or it does not exist. As an admin, if I put in an admin token here, we see that we can access all posts. We see there is an author here beginning with 18b and an author here beginning with be8, and that is because admins have full CRUD access, create, read, update, and delete over all collections in the project. This is the exact same request, but with Beth's token, and we see here that if we hit send, we now only get one item returned. In turn, Beth can only update this item or delete this item, but not those created by other users. This is really nice because it means access control is set up and controlled by directus, which means you cannot inadvertently access data that you're not allowed to in your own application because it's all handled at a direct us level. So that's just a quick example of how access control works inside of Directus. I will see you next time on Authentication Avenue.","published",[135],{"people_id":136},{"id":137,"first_name":138,"last_name":139,"avatar":140,"bio":141,"links":142},"82b3f7e5-637b-4890-93b2-378b497d5dc6","Kevin","Lewis","a662f91b-1ee9-4277-8c9d-3ac1878e44ad","Director of Developer Experience at Directus",[143],{"url":144,"service":145},"https://directus.io/team/kevin-lewis","website",[],{"id":148,"number":149,"year":150,"episodes":151,"show":156},"ff7886c3-8457-49e6-a2c7-f7d526d518ce",1,"2025",[152,122,153,154,155],"0df4af9a-442f-4fd5-97b5-3c38e6644e75","c6491b5a-5afa-4ce8-8958-d15ecf4a3369","ae9ce140-b94f-455f-8e94-e623e3d4da76","6d68c3bc-e3b4-49f2-81fb-6bd7ddb45995",{"title":157,"tile":158},"Authentication Avenue","17eeb7e8-08e3-4a21-8bc0-d27857ac8df6",{"title":8,"meta_description":8},{"id":153,"slug":161,"season":148,"vimeo_id":162,"description":163,"tile":164,"length":165,"resources":8,"people":8,"episode_number":166,"published":129,"title":167,"video_transcript_html":168,"video_transcript_text":169,"content":8,"seo":170,"status":133,"episode_people":171,"recommendations":173},"why-do-tokens-expire","1048670160","You can't have access forever. In this skip down Authentication Avenue, Kevin answers \"Why do tokens expire?\" and shows you how to get new ones.","f1fa8472-da39-4d05-ad8d-8e891e8b1f55",7,3,"Why do tokens expire?","\u003Cp>Speaker 0: Hey, developers. Welcome to authentication avenue. You know how spies in movies have secret codes that expire after a single use? Well, in modern applications, we do something similar with access tokens. Today, we're exploring why these digital passes have expiration dates and the clever system that keeps users logged in securely.\u003C/p>\u003Cp>Imagine you're visiting a big amusement park. When you arrive you get 2 things, a ride pass that's good for just one day, that's like your access token, and a special VIP card that's good for the whole year, That's like your refresh token. Now when your day pass expires, you don't need to go back to the ticket counter and buy a new ticket. Instead, you can show your VIP card at the special kiosk, and it will print you a fresh day pass on your next visit. And this is exactly how modern applications handle access.\u003C/p>\u003Cp>Your access token is like that day pass. It lets you go on rides or in our case make API requests, but it expires quite quickly. The refresh token is like the VIP card. It's valid for much longer and lets you get new access tokens without logging in again. But why not just make the access token last forever?\u003C/p>\u003Cp>Well, imagine if someone stole your day pass, they can use it till the end of the day. But, if they stole a much longer pass, say for the whole year, they could keep using it forever. And that's why we keep access tokens short lived, it's safer that way. In Directus, here is how it works. When you log in, you get a package of data containing an access token, usually valid for 15 minutes, although you can configure that, A refresh token, valid for much longer, and an expiration time stamp.\u003C/p>\u003Cp>Now when your access token expires, you call the refresh endpoint with your refresh token, and then get a fresh package of tokens. And if you want to log out, you can destroy these tokens, just like shredding your park passes so nobody else can use them. This is especially important when using shared computers or if you think your tokens might be compromised. So there you have it. Token expiration isn't just an inconvenience, it's a crucial security feature that helps keep your application safe.\u003C/p>\u003Cp>Let's see how it works in Directus. I wanna show you how to interact with Directus' authentication endpoints via API, and we're going to start with the login endpoint. So this is a post request to /auth/login. In the body, we provide the email and password, and when we send that, we receive a packet of data back. We what?\u003C/p>\u003Cp>Oh, there we go. We have an an access token, which we can use in order to make requests. We have a refresh token and an expiry time. This is 30,000 milliseconds or 30 seconds. I've set it to be quite short in this project to demonstrate my point.\u003C/p>\u003Cp>Now we can use this access token here in order to authenticate requests and retrieve data, but as you might remember, we've only set this to 30 seconds before expiry. So if I try and hit send again, we see that the token has expired. This whole token is no longer usable. So what do we do? We won't always be able to send off an email and password because we may no longer have access to them.\u003C/p>\u003Cp>You don't necessarily want to store them, so we use the refresh token. Now the refresh token also expires, but a much, much longer time. I believe the default is 7 days, but it is configurable just like the access token is, which I set to 30 seconds here. So we have this refresh token, and we also have a refresh endpoint, post slash auth slash refresh. We provide our refresh token, and what we receive back is the same data packet, an access token, a refresh token, and the amount of time until it expires.\u003C/p>\u003Cp>You can now use this new access token in order to authenticate requests. And once again, this refresh token is now spent, it no longer works. You can now use the new refresh token in order to receive a new packet of data. And once you're done and you want to log out, you can hit /auth/logoutpost with your refresh token, that is not the refresh token, with your refresh token, and you will receive a 204, which is a successful request, but with no content returned. And now the tokens, including the refresh token, is, invalidated, and you can no longer access it.\u003C/p>\u003Cp>Now when you're working with the SDK by comparison, the SDK handles all of this for you. It will handle the storage of your tokens, it will handle the refreshing of your tokens for you as soon as you log in. However, we do also provide explicit, methods, request, refresh, here it is, and log out, a refresh function and a log out method in order to run those same commands as the API. But in most use cases, you won't need these. You log in, and as you make requests, the SDK will handle the refreshing of tokens on your behalf.\u003C/p>\u003Cp>So hopefully, that helps explain the relationship between access tokens, refresh tokens, expiry time, and how you actually work with the API in order to generate and regenerate them. Thank you for joining me on Authentication Avenue, and I'll see you next time.\u003C/p>","Hey, developers. Welcome to authentication avenue. You know how spies in movies have secret codes that expire after a single use? Well, in modern applications, we do something similar with access tokens. Today, we're exploring why these digital passes have expiration dates and the clever system that keeps users logged in securely. Imagine you're visiting a big amusement park. When you arrive you get 2 things, a ride pass that's good for just one day, that's like your access token, and a special VIP card that's good for the whole year, That's like your refresh token. Now when your day pass expires, you don't need to go back to the ticket counter and buy a new ticket. Instead, you can show your VIP card at the special kiosk, and it will print you a fresh day pass on your next visit. And this is exactly how modern applications handle access. Your access token is like that day pass. It lets you go on rides or in our case make API requests, but it expires quite quickly. The refresh token is like the VIP card. It's valid for much longer and lets you get new access tokens without logging in again. But why not just make the access token last forever? Well, imagine if someone stole your day pass, they can use it till the end of the day. But, if they stole a much longer pass, say for the whole year, they could keep using it forever. And that's why we keep access tokens short lived, it's safer that way. In Directus, here is how it works. When you log in, you get a package of data containing an access token, usually valid for 15 minutes, although you can configure that, A refresh token, valid for much longer, and an expiration time stamp. Now when your access token expires, you call the refresh endpoint with your refresh token, and then get a fresh package of tokens. And if you want to log out, you can destroy these tokens, just like shredding your park passes so nobody else can use them. This is especially important when using shared computers or if you think your tokens might be compromised. So there you have it. Token expiration isn't just an inconvenience, it's a crucial security feature that helps keep your application safe. Let's see how it works in Directus. I wanna show you how to interact with Directus' authentication endpoints via API, and we're going to start with the login endpoint. So this is a post request to /auth/login. In the body, we provide the email and password, and when we send that, we receive a packet of data back. We what? Oh, there we go. We have an an access token, which we can use in order to make requests. We have a refresh token and an expiry time. This is 30,000 milliseconds or 30 seconds. I've set it to be quite short in this project to demonstrate my point. Now we can use this access token here in order to authenticate requests and retrieve data, but as you might remember, we've only set this to 30 seconds before expiry. So if I try and hit send again, we see that the token has expired. This whole token is no longer usable. So what do we do? We won't always be able to send off an email and password because we may no longer have access to them. You don't necessarily want to store them, so we use the refresh token. Now the refresh token also expires, but a much, much longer time. I believe the default is 7 days, but it is configurable just like the access token is, which I set to 30 seconds here. So we have this refresh token, and we also have a refresh endpoint, post slash auth slash refresh. We provide our refresh token, and what we receive back is the same data packet, an access token, a refresh token, and the amount of time until it expires. You can now use this new access token in order to authenticate requests. And once again, this refresh token is now spent, it no longer works. You can now use the new refresh token in order to receive a new packet of data. And once you're done and you want to log out, you can hit /auth/logoutpost with your refresh token, that is not the refresh token, with your refresh token, and you will receive a 204, which is a successful request, but with no content returned. And now the tokens, including the refresh token, is, invalidated, and you can no longer access it. Now when you're working with the SDK by comparison, the SDK handles all of this for you. It will handle the storage of your tokens, it will handle the refreshing of your tokens for you as soon as you log in. However, we do also provide explicit, methods, request, refresh, here it is, and log out, a refresh function and a log out method in order to run those same commands as the API. But in most use cases, you won't need these. You log in, and as you make requests, the SDK will handle the refreshing of tokens on your behalf. So hopefully, that helps explain the relationship between access tokens, refresh tokens, expiry time, and how you actually work with the API in order to generate and regenerate them. Thank you for joining me on Authentication Avenue, and I'll see you next time.","a9f13359-7b06-4f50-a2c3-da41d60e927c",[172],"5b464654-0785-4256-9c30-9e61ee7f8205",[],{"reps":175},[176,232],{"name":177,"sdr":8,"link":178,"countries":179,"states":181},"John Daniels","https://meet.directus.io/meetings/john2144/john-contact-form-meeting",[180],"United States",[182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231],"Michigan","Indiana","Ohio","West Virginia","Kentucky","Virginia","Tennessee","North Carolina","South Carolina","Georgia","Florida","Alabama","Mississippi","New York","MI","IN","OH","WV","KY","VA","TN","NC","SC","GA","FL","AL","MS","NY","Connecticut","CT","Delaware","DE","Maine","ME","Maryland","MD","Massachusetts","MA","New Hampshire","NH","New Jersey","NJ","Pennsylvania","PA","Rhode Island","RI","Vermont","VT","Washington DC","DC",{"name":233,"link":234,"countries":235},"Michelle Riber","https://meetings.hubspot.com/mriber",[236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,422,423,213,424,425],"Albania","ALB","Algeria","DZA","Andorra","AND","Angola","AGO","Austria","AUT","Belgium","BEL","Benin","BEN","Bosnia and Herzegovina","BIH","Botswana","BWA","Bulgaria","BGR","Burkina Faso","BFA","Burundi","BDI","Cameroon","CMR","Cape Verde","CPV","Central African Republic","CAF","Chad","TCD","Comoros","COM","Côte d'Ivoire","CIV","Croatia","HRV","Czech Republic","CZE","Democratic Republic of Congo","COD","Denmark","DNK","Djibouti","DJI","Egypt","EGY","Equatorial Guinea","GNQ","Eritrea","ERI","Estonia","EST","Eswatini","SWZ","Ethiopia","ETH","Finland","FIN","France","FRA","Gabon","GAB","Gambia","GMB","Ghana","GHA","Greece","GRC","Guinea","GIN","Guinea-Bissau","GNB","Hungary","HUN","Iceland","ISL","Ireland","IRL","Italy","ITA","Kenya","KEN","Latvia","LVA","Lesotho","LSO","Liberia","LBR","Libya","LBY","Liechtenstein","LIE","Lithuania","LTU","Luxembourg","LUX","Madagascar","MDG","Malawi","MWI","Mali","MLI","Malta","MLT","Mauritania","MRT","Mauritius","MUS","Moldova","MDA","Monaco","MCO","Montenegro","MNE","Morocco","MAR","Mozambique","MOZ","Namibia","NAM","Niger","NER","Nigeria","NGA","North Macedonia","MKD","Norway","NOR","Poland","POL","Portugal","PRT","Republic of Congo","COG","Romania","ROU","Rwanda","RWA","San Marino","SMR","São Tomé and Príncipe","STP","Senegal","SEN","Serbia","SRB","Seychelles","SYC","Sierra Leone","SLE","Slovakia","SVK","Slovenia","SVN","Somalia","SOM","South Africa","ZAF","South Sudan","SSD","Spain","ESP","Sudan","SDN","Sweden","SWE","Tanzania","TZA","Togo","TGO","Tunisia","TUN","Uganda","UGA","United Kingdom","GBR","Vatican City","VAT","Zambia","ZMB","Zimbabwe","ZWE","UK","Germany","Netherlands","Switzerland","CH","NL",1773850428136]