 So hi everyone, just going to talk for for a few minutes here about the data store in DHS to what it is how to use it in your DHS to applications. And some way, particularly talking a little bit about some ways to make sure that you're using it in a secure way. I won't get into too many technical details of how it works or how to use it in code. We can talk about that in the Q&A afterwards if you want but also we'll be covering that in a session in the DHS to developer Academy workshop to next week, which is four days long I'm sure Deborah will talk about that after after I'm done. But just wanted to start by talking about what the data store is and why you might want to use it. So the DHS to data store is a JSON object store basically it's a place where you can store information that doesn't fit into the DHS to normal metadata schema. So you can put any information in there. And there are actually two different data stores there's one that's available to all users of DHS to which can then be restricted to only a smaller group of users or user groups as well. And using the sharing settings that are the same sharing settings that you might set for an indicator or a dashboard or those types of things. And then there's a user data store which is available only to one DHS to user. So if you put something if a user put something into their user data store no other user can see it. And so it's important to keep in mind that there are both of those available and you can use them for different things in your applications. So within the data store and the user data store there are namespaces and and these namespaces are basically just a collection of key value pairs. So usually an application will use one namespace and and will then store any information that they want to keep track of into the keys and values within that namespace. So you can find information about the how to do this through the API, and how to how it the data store is structured in the documentation in docs at docs that Jesus to the Lord, I put the full link here and we'll share the slides after this as well. You can also view the data store through the data store application in your DHS to instance. So you can actually explore what's stored there and see the key namespaces keys and values that are available to your DHS to user that you're logged in with. There are a number of things that an application might want to use the DHS to data store for. I can't list all of them because the whole point is that you can use it for most anything, but some of the common use cases that we see are storing settings for your application, which means that you might want to set. The, I don't know the name of the metadata that your application is referring to so they are the idea of the metadata that your application is referring to so if you have an application that is for managing a particular org unit or something, you might want to save the the idea of that org unit so that every time a user comes back to that application, they don't need to re enter the or find that or unit again if it's always going to be used for that one or unit. You could even have two different types of users of your application one that has the ability to set the or unit for that app. And the other that only has the ability to use the application and not to change which or unit it's associated with. So that's, that's kind of a contrived example but there are a lot of different things that you might want to save settings for in your application. And that's one of the main use cases that we see for DHS to data store use in apps. Another is saved objects, which is a bit more complicated, and we'll get into this a bit more on the in the session next week so I'm not going to go into it too long here. But what that is is basically the same as the analytics applications in DHS to so if you go to the data data visualizer app, you will see that you can file new file save file open, and you'll see a list of visualizations that you or other people have created that have been shared with you. If you want to recreate that in a custom application with a custom type of visualization, you can use the data store for that. So there is a abstraction layer on top of the data store that I'll talk about at the end and you go into more detail next week that allows you to save and load individual objects to the data store and basically keep track of them and update them, as well as share them with different users. Those are the two main use cases that we see but there are many others as well because as I said you can you can save and load any any JSON object so any information you want into that data store. Now I'm going to talk a little bit about some security considerations because I think this is very important for understanding how the data store works and how to use it in a secure way. It's tempting just to take some information that somebody types into your in your app, save it into the data store, and then forget about it and load it later, maybe maybe allow the user, the users of your app to edit it. If you don't do some take some precautions to make sure that that information is secure. It's available to every user of DHS to, and also by default every user in DHS to can edit that information so that in most cases isn't what you actually want you don't want a guest user who has just get been given access to know metadata no data store or anything to be able to edit the the settings of your app or to delete visualizations that your users have created those types of things. So it's important to keep security in mind, especially also if you're using the data store to store things like credentials for the DHS to or for other systems. There's a guide on developers that DHS to org the developer portal that is for submission to the app hub, and that has a security section which you can find at this link here, and you can also just go to docs guides app hub, and then go to the security section, and there's a lot of recommendations in that guide, some of which pertain to the data store. So I'd recommend that first first off look at that guide and follow those recommendations. And we'll also be adding some more guides and documentation around how to use do how to make your application secure not just with the data store but with other things as well. And that will be coming coming soon, but for now look at the app hub guidelines for sort of the best practices today. One thing that an app can do and most apps should do is to reserve a namespace in the data store. So if you're going to use the data store to save settings or to save objects. You need to share that. Unless you need to share the data that you're saving into that namespace with other applications, you should reserve it, which means that you put it in the manifest file for your web application. And what that does is once an application is installed that reserves say my app as the namespace key. Then no other application can be installed that also tries to reserve the my app namespace. That means that it will prevent other apps from being installed it will also prevent other applications from accessing that information, because only users that have been given access to your app can see that reserve data store namespace key or namespace. So this allows you basically to restrict by default have a little bit better security where if a guest user is added to DHS to they haven't been given access to your custom DHS to application. They won't have access to that namespace key by default. So that's kind of the bare minimum that we would recommend for securing the namespace for your application in the data store. It's possible unless you're sharing, as I mentioned unless you're sharing with users that don't have access to your application, you should always reserve a namespace. And you should also make sure that the namespace you choose is unique to only your application so the example I gave where I say my app should be the namespace key is probably a very bad one, because then multiple people, multiple applications will try to reserve that same namespace. And if someone else reserves it and then you some of the user tries to install your application next, your application won't be able to be installed because somebody else has already used it. So I recommend using a name that is long and unique. It doesn't have to be super human readable it can be something that's kind of complex. It should be specific to your application probably should have the name of your application in that namespace key, and then also be unique enough that someone else isn't probably going to make a an application that's called the same thing. In order to reserve a namespace there are two methods, two mechanisms for doing this one is a slightly easier way that's been added recently to the the app platform. You can in D2.config.js of your application set the data store namespace key to whatever the namespace you want to reserve is, and that will be automatically injected into the manifest of the app that you build. If you're not using the platform you can write it you can add it directly to manifest web app in your non platform application. And in that case it goes under the activities DHS to namespace key, and then you put the name of the namespace that you want to reserve there. Once you have a namespace in the data store that you've probably reserved because it's only used for your application but maybe it's not as well. You should make sure that you are using the sharing functionality if possible for that data store namespace and the keys within it. This means that namespaces by default can be shared with any user in DHS to or they can be read and written to by any user in DHS to which means it might be problematic because you don't necessarily want all users to be able to see and right to those keys. You can use the sharing settings just like any other metadata to assign certain users and groups to view and edit the keys that you create in your namespace. You can find more about that in the documentation as well for how to do that specifically, you use the sharing namespace it's in docs.2.org in the data store section of the web API guide. That's the same link that I shared earlier in the slides. I mentioned earlier about using credentials and so it's recommended not to store credentials in the data store that's especially not DHS to credentials. That's because usually you don't want to store user credentials there because then it's not actually the user that's entering those credentials and you've lost some of the security capabilities of that basically credentialing system. But in some cases it might be unavoidable or necessary to store credentials for some external system in the DHS to data store so that you can synchronize data between DHS to an external system, or you can fetch data from a some global publicly available store that needs credentials something like that. And in these cases, there are three rules that you should follow. Number one, you should always store credentials in the user data store if possible. And that means that if you want the user to enter their credentials and then not have to enter those credentials again, you can put it into the user data store and no other users will be able to access those credentials, which is a good thing. And also that user will will be able to access them later so it doesn't reduce the usability of your application. If you can't use the user data store which means that you need to share those credentials with multiple users, you can use the data store but make sure to set the sharing permissions so you probably don't want every single user to be able to both read and write the credentials in that data store. You probably want them to read the most most of the users that access your application maybe want to be able to read it, but maybe only admin users should be able to write the credentials to the data store or something like that. And that's depends on what what credentials you're using how you're building your application there's a lot of considerations to take into account there. And then the third, this is a little bit kind of of a hidden feature in DHS to, but it's very important to set when you're using the data store to store credentials both the user data store and the data store. And that's to set the encrypt equals true flag. And when you do this, it might seem that not like nothing happens. So you set the encrypt equals true flag when you create a key value in the data store. And then you read that value later and it's not encrypted. It just looks like the same data that you put in. But that's because what this encrypt equals true flag does is it encrypts the data at rest. This means that what when the DHS to server accepts the information from the, the API, it then encrypts it and stores it in the database. And when it is read later it uses that same encryption key to decrypt the data from the database and return the information. But if someone a hacker was able to get access to the database of your DHS to instance, and they wouldn't be able to see those credentials they would need to go through the DHS to server, which would need to either they would either need to have in access to the DHS to server itself, or they would need to have a valid user credential with proper sharing permissions to access it through the API. The docs that I mentioned earlier also have information on encrypting data store keys, so you can learn more there, and we'll be adding more information to that to the guides on security as well. So I'm going to just introduce very quickly the app service data store application service, which is a react hooks implementation for accessing the data store. There's not a lot of documentation there yet, but it is starting to get more use so I think we're going to be promoting this to a fully supported service, which should have documentation will be adding documentation will also be adding sharing in this data store service, and will also be probably integrating it into the app runtime so it's available out of the box to all these just to applications. And what this does today is it allows you to save and load application settings from both the data store and the user data store. It also lets you save and load saved objects like visualizations from the data store and user data store in a kind of more user friendly way than you might if you were actually using the data store API directly. And then soon it will as I mentioned allow you to set sharing settings and encryption on the data store keys that you're creating. And we'll be creating some more documentation and how to use coming very soon. And I'll also be diving into how to actually use this in your application what job what the code of your app should look like to use this data store service in the academy next week. I believe that's all I have in terms of slides. So I think that's the end of my presentation but we can. Yeah, open it up to any questions I can dive deeper into any of these topics or any anything else that anyone wants to talk about maybe we stop the recording and go from. Thank you so much. Thank you so much.