if I use Xam.Plugins.Settings to save, for example, token оr anything else, what level of security does this give me? Can I expect a greater level of security if I create my own Settings service in each platform project, which simply uses the default Api?
How and where do you store data such as a token and userName? Whether you use encryption or some paid plug-ins? I've heard a little about them in Unity, but I'd like to know more.
The Settings Plugin saves specific properties directly to each platforms native settings APIs (NSUserDefaults, SharedPreferences).
For example, in Android, the SharedPreferences are a file that is stored on the device filesystem, within the app's data directory, set with permissions that only the specific application can read/write. However, as everything, it can be "hacked", if you have root privileges, and try to access the filesystem, you can always see what's in the file.
What you can do, is to encrypt the data you save in the Properties, so you add an extra layer of security.
Related
I have an internal app (not a published one, only used within our Google Workspace domain) which is a command line tool to update the contents of some Google Sheets. It currently uses the https://www.googleapis.com/auth/drive scope and works fine.
I want to minimize the privileges of the authorization token that this app caches, and by reading the documentation it seems that I should be able to use the https://www.googleapis.com/auth/drive.readonly scope to find the file I want, and also https://www.googleapis.com/auth/drive.file to grant write access to only a specific file.
With the reduced scopes, I am not surprised to get an error like:
appNotAuthorizedToFile: The user has not granted the app 566375348811 write access to the file 1UsItGhBHwRaodHbv5g1LCrSESUZBkskDvKDkbGjREjI
The only relevant documentation talks about integrating apps with Google Drive and using the Drive Picker UI which I expect does this authorization behind the scenes. Since this is an internal command line tool, I really don't want to go that route.
Hence the question:
How do I open a file in a command line application using the https://www.googleapis.com/auth/drive.file scope?
I'm OK even if I need to set some magic metadata on the file to make it accessible.
Update
As I got a couple of responses saying that when using drive.file it is not possible to access files which are not created by the application, I am putting some supporting documentation here to show why I think it is possible:
The API-specific auth info is the first document on the Google Drive API page, and it specifically mentions:
So, when possible, use non-sensitive scopes as they narrow access to
specific functionality needed by an app. In most cases, providing
narrow access means using the
https://www.googleapis.com/auth/drive.file per-file access scope.
Further down the page it mentions:
This scope enables users to select the specific files from Google
Drive, and through the Google Picker, that they want to allow your app
to access.
I understand this to mean that it is possible to open files which were not created by the app, even when using drive.file.
My problem is that the document goes on to explain:
Many apps work with per-file access without any changes. If you are
currently using your own file picker, we recommend switching to the
Google Picker which fully supports the drive.file scope.
Well, since I am using a command line app, I cannot use the Google Picker, so I am asking how to implement my own. I do understand that the picker itself needs to have access to all the files (hence the need for a drive.readonly scope), but to actually be able to write the files, it needs the elevated permission of drive or the more restrictive per-file access of drive.file.
If I simulate an authorization request for drive.file I get a prompt which explains that authorizing the request will grant my app to:
See, edit, create, and delete only the specific Google Drive files you use with this app ℹ️
Clicking on the information icon I get a more verbose explanation which reads like it support opening any file I authorize:
This app wants permission to create new files or change existing files
that you open with this app. Once authorized, the app can:
See these files
Upload and download these files
Delete these files
See the names and emails of people you share these files with
Share and stop sharing these files with others
Organize these files
There may be private information in your Google Drive, like financial
records, medical reports, photos or tax info.
There are also other examples of applications like ZIP Extractor or diagrams.net or Photo Editor which use the drive.file scope (based on the authorization prompt), and which I can use to open and edit files that were not created by them.
I am posting this as an answer, to demonstrate an ugly "workaround" for the issue.
TL;DR: Use a web based frontend to authorize access to files. Once the app is authorized, the command line app inherits the permissions.
More step by step instructions, assuming we already have a working command line project:
Go to https://myaccount.google.com/permissions and revoke all access I have granted to my app.
Follow the instructions at the Drive Picker API to update my current GCP project.
Create an API key. OK to be unrestricted, but I restricted it to https://localhost:9843
Create a new OAuth 2.0 client ID of a "Web application" type (my current one is "Desktop" type and that would not work). Authorize https://localhost:9843 as a JavaScript origin.
Copy the helloworld.html example at the bottom of the Drive Picker API guide which is also on GitHub with the following modifications:
Set developerKey to the API key created above
Set clientId to the new OAuth 2.0 client ID created abovce
Set appId to the numeric project ID of my GCP project
Add 'include_granted_scopes': true to the call to window.gapi.auth.authorize
Update createPicker to make it easier to find the files I want. E.g., set the mime type filter to application/vnd.google-apps.spreadsheet.
Host the example in a browser with ruby -rwebrick/https -e 'WEBrick::HTTPServer.new(:Port => 9843, :DocumentRoot => ".", :SSLEnable => true, :SSLCertName => "CN=localhost", :SSLCertComment => "Autogenerated" ).start'
Now, if my command line app fails to edit a file, I can use https://localhost:9843/helloworld.html to grant access to the file, and my command line app can then edit that file.
If you check the docs for the scope you will find it says.
https://www.googleapis.com/auth/drive.file View and manage Google Drive files and folders that you have opened or created with this app
This gives your app access to files that the app itself created or has previously opened.
You should also know that there is no way to limit authorization to a single file. Authorization is all or not thing.
How do I open a file in a command line application using the https://www.googleapis.com/auth/drive.file scope?
You make sure that the file was created by the app itself. using files.create. If the file was created by any other app the you cant access it using the drive.file scope
There is one note though if you have https://www.googleapis.com/auth/drive.read-only scope and you open that file to read it. the line where it says opened or created with this app implies to me that once you have opended it for read in this app that you would then be able to use it with https://www.googleapis.com/auth/drive.file but its not something I have tried.
Another thing is im not sure what you mean by open the google drive api is a file storage api its not going to let you see the contents of the file your going to have to download it and open it locally. Have you considered going though the Google sheets api if you want to read and write to it programmatically?
Initially I would like to inform you that I am using ember 2.10.
Can anyone tell me how to make a login system without a token?
I am developing an offline application with Ember and Electron and I need to make the login system without using external APIs.
If I understand you right, you want to create an application that will support few users. It is possible. You will need to perform following steps:
Install ember-simple-auth plugin. It makes auth-related things much easier
Create custom authenticator that will take a login and password or something from your users and save some identifier in session
Create login and register routes, where users will be able to login or create new credentials
Most probably you will not need an authorizer, because you don't have server api and don't send requests to it
Bear in mind that this will be zero-security system, even if you will use some encryption, because js code is not secured well from exploration. Also bear in mind that electron most probably stores user's data in user's home directory (I can't say for sure as I didn't work with electron, but node-webkit does that). In this case having different windows (or what OS your users will use) users is enough to separate data and you actually don't need any login system.
I'm using the enterprise library and AZ Man to authenticate users into my winforms application. I've got the code working fine using the XML file. I don't understand how to securely deploy the application though.
In app.config there is a path to the XML file. There doesn't appear to be anything stopping a user from opening this XML file in azman.msc and giving themselves access they shouldn't have.
If we put the XML file on the server and make it read-only to user, there is nothing stopping the user from copying everything locally and changing the app.config pointer to a local file they can write to.
There seems to be something major I'm missing here, but I've been reading and can't figure it out.
I think what you'd probably want to do is create your authorization store inside of Active Directory instead of an xml file. You can find instructions on how to do that here. Here's the interesting bit:
Working with Authorization Stores
Creating an Authorization Store
Open Authorization Manager, right-click Authorization Manager, click
Options, select Developer mode, and then click OK.
In the
Authorization Manager console, right-click Authorization Manager,
click New, and then click Authorization Store.
Select either Active
Directory or XML file as the store type.
Type a complete store name in
the Store name box, or use the Locations button to select a location
by using the New Authorization Store dialog box.
If it is an Active
Directory authorization store, use the LDAP name -- for example
CN=myStore,CN=Program Data,OU=Authorization,DN=myCompany,DN=com. If it
is an XML authorization store, use a path and file name that will be
valid at run time -- for example C:\AuthStores\MyStore.xml.
Type a
description of the new authorization store in the Description box, and
then click OK.
NOTE: Authorization stores can be created only in Developer mode. See
the "Setting the Authorization Manager Options" section of this
article for instructions about setting Developer mode.
Once you have the store created in Active Directory you can restrict who has write access to AD and the AzMan store. You can also create a store in SQL if you so desired.
Another option you have is to encrypt your connection strings to AzMan in your app.config. And since you're using Enterprise Library, I think you have the option of encrypting the entire AzMan xml file. None of it is completely bulletproof, but your users would have to go through a lot of trouble to hack your application. But if your users are willing to go through that much effort to break into your program, you don't have a programming issue - you have a personnel issue that needs to be addressed (my opinion, anyway).
This looks like a good walkthrough on encrypting app.config sections. Essentially, I think the idea is you create a new RSA key on your workstation and use that key to encrypt the app.config sections. Then import that key to a server and grant your users read access to that key. I'm sure there are plenty of other solutions for encryption if you Google it (or search here on stackoverflow).
Microsoft's policy says:
The following requirements apply to applications that receive the
location of a user's mobile device:
2.7.3 Your application must provide in-application settings that allow the user to enable and disable your application's access to and use of
location from the Location Service API.
I included ID_CAP_LOCATION in my manifest for an AdMob (google mobile advertising) control only - Do I need to add that in-app settings disabling location and tell user that the application uses location services on the first launch for successfully passing the certification?
In Google's own documentation, they say:
Google asks that you only specify location data if that information is already used by your app
The suggested interpretation of Microsoft's certification guidelines would be that to be accepted on the store, if you're going to use the location of the user (even if only to pass to an advertising control) you should be up front about that and allow your customer to disable that option.
So, to summarize, I would suggest not using the location unless your app has another reason to do so (to keep Google happy), and if you choose to use locations, I would recommend being up front with (one-off) message on first launch, and the ability for your customer to disable it (to keep Microsoft happy).
Is there a way to allow the user to add additional items to one group in the settings bundle? Specifically, I a would like the user to be able to specify a list of URLs and Site Names within Settings. The functionality is almost exactly the same as the Twitter app that allows for a list of usernames and passwords and in the mail app where the server name, inbound and outbound email server names/addresses are maintained. I am familiar with doing this with archive, CoreData and SQLite within the app, but would prefer to keep key settings outside the app as I would like to intentionally distance the config data from the user interface.
Thanks
Derrick
Unfortunately you're pretty limited with what you can do in the settings. There isn't any way to run code, so there can be no add buttons or changes to the model - its basically predefined key value pairs. Twitter and mail are first-party apps so they can do things in settings the rest of us can't.