I've created an application that stores username and password information, inserted by the user, using the Application Settings. This application is suppose to be mobile, I mean, you should be able to carry it from one computer to other without losing information. But I've notice that when I change the folder the app is in, all settings are lost. I've run the internet in search for answers, but all I've found is storing the data in XML files.
Related
I have a VB6 application that in parts opens other applications. These applications can be created by approved third parties for integration purposes.
I am trying to find a way that I can open these securely and ensure the application that gets opened is the one intended.
I want to ensure the .exe cant be replaced by another with the same name. The main application has access to an SQL database. So I was thinking of a hashed key but I then run into a problem where I would need to create a new release for each new integration.
Any suggestions would be fantastic!
I developed a desktop application that saves projects locally to disk. Each project is a directory that consists out of many files. If certain files are missing the project is corrupt.
I want to add Google Drive support to my desktop application, so the user can load and save projects directly to the cloud. For clarification, the desktop application talks directly to the users Google Drive. There is no 3rd-party webservice involved.
I want to make the installation process as easy as possible for the user. I know the user can generate an API key for his account, but this is to technical for my target audience.
My question is, can I create a Google Drive App that shows up in the market place, that my desktop application can use to access the files on the users drive? Or is the market place meant to be only for 3rd party web-services that can access someones account?
TLDR; I want my desktop application being able to access Google Drive files. Is it possible to create a 1-2 click installation process that my app can access these files? Setting up an API key is too complicated for my users.
I want to make the installation process as easy as possible for the user. I know the user can generate an API key for his account, but this is to technical for my target audience.
First off an API key is only used to access public data. You will need to have your user authorize your application access their google drive account using Oauth2.
You will need to create a project on google cloud console and create Oauth2 credentials which will allow your application to request access of the user.
I want my desktop application being able to access Google Drive files. Is it possible to create a 1-2 click installation process that my app can access these files? Setting up an API key is too complicated for my users.
Its not exactly one click but a user will have to be signed in to their google account and then click the authorize button.
I want to send info between a desktop/laptop/tablet app and Windows Phone. One possibility is to send data to the SkyDrive account and have the other end pick it up from there. Is this feasible? What I have in mind is the "Windows 8" app running on the desktop, laptop, or tablet allowing the Windows Phone app[s] to send data to its account. Is this possible, such as by providing the Windows Phone app with the Skydrive login info, or...???
From all the other questions you've posted around this query, it sounds like you want to put a mechanism in place to communicate between a Windows 8 app and a windows phone app. I would recommend you look at building a service to handle the communication instead of trying to leverage mechanisms that weren't designed for what you want to achieve.
In direct answer to the this question, though, you can probably achieve it in this manner, but what happens if the user deletes the file you create?
So, SkyDrive is unique to a user, not a device. This means if your application is running on more than one device you can use SkyDrive as a shared, unified storage option. Not just for files but also for application settings. There's an SDK for every platform, not just MS.
Here's what you need to consider.
The roaming API in Windows 8 puts information in a protected area of SkyDrive. As a result, the user cannot delete or screw up the files stored there. To that end, using SkyDrive as a shared location (like you are asking) doesn't have this benefit. The user can screw with your files or delete them - and wreck your app. There is no such thing as protecting your app files in SkyDrive (at this time).
Specifically, to your question:
The authorization model for SkyDrive requires a token that cannot be practically cached for any app. Also, you cannot cache credentials because you never get the credentials in the first place - you only get the resulting token. Listen, you would violate every possible best practice if you //asked// the user for their username and password and stored them. Please do not do this.
The final answer is this: an app on multiple devices can use SkyDrive as a shared storage solution for files and settings (like XML files) - but the developer needs to understand the risk and mitigate that (mitigation might be easy for your app). The user, on every device, would need to sign in and grant each application access to it folders. And, that's it.
I've added a setting to ServiceConfiguration.cscfg with the idea that it will allow me to turn on/off a feature of the MVC app. The code correctly reads the setting however while running the app in local dev compute emulator, I don't see the ServiceConfiguration.cscfg file in the .csx directory. I only see the ServiceDefinition.csdef file which has the key but not the value. I want to change the value.
The idea is that I have a text file I can alter after deploying that will allow me to turn on/off parts of the app by opening text file on Azure and making changes.
I don't want to be dependent on Azure Storage or a hop off the Azure box.
What is the best way to change my own app config setting in azure?
Well,
Your path is correct. ServiceConfiguration.cscfg is one of the places where you could have service wide settings. And there is one gotcha here, you can't dynamically change the service configuration with local Azure emulator. If you want to change something in the service configuration, you have to stop your debugging session, change the setting and start new session. Only in live Azure Environment, you can change the service configuration, and it will be propageted to all instances.
I intentionally bolded service wide settings. With full IIS mode (available since SDK 1.3) you can have multiple web sites per single Web Role. That would mean multuple applications. Now I would not want to mess setting for one of the applications, with settings for the other. That is why I would put an application wide settings in an Azure Table. And your application may query this table every N seconds/minutes, depends what is your targeted response time.
I wonder what are your thought begind the "I don't want to be dependend on Azure Storage" statement? Before all, you are developing application for the Windows Azure platform. Ain't you going to have any dynamic data? File uploads or file generation or anything like that? Check out the Windows Azure Storage SLA. I don't think a Windows Azure storage (in your case I suggest Tables) would be in any harm for your application. Especially when your service deployment is in the same geographic region as your storage account.
I have a python application designed to run as a service on Linux, and I've been asked to install it on a Windows XP box in an office where there are no Linux machines (for me, this makes it a bizarre and confusing place as I have virtually no experience developing for Windows).
On Linux the application has its own user, and the application and database credential file reside in an encrypted folder accessible only by that user. (I'd like to state that I am not a cryptologist, and that if there are already glaring security errors in this set up I'm very happy to have them pointed out to me!)
How can I achieve an equivalent level of security by similar or different means on a Windows XP machine? That is to say, how can I prevent those who have access to the computer or the disk altering the program or reading the credentials?
A little background: the host windows box is a workstation used every day by users with non-administrative privileges. The secure assets are personal data roughly as sensitive as, for example, a school report. The application is intended to be used by about 10 people who authenticate to the application with individual passwords (stored salted and hashed in the database).
There is a very similar question that received the answer:
on Windows you would store the credentials in the registry in a location protected by an ACL
However, it doesn't touch on the aspect of protecting the program files, and further it seems to assume a higher level of Windows experience than I currently enjoy :) I have no idea how to protect registry items with an ACL, nor how I would then be able to access the protected keys from my program. Simple instructions for a developer in an unfamiliar environment would be greatly appreciated!
Your question is unclear about what your application does and what your security requirements are. I'm going to make some assumptions, and provide an answer based on them. If these assumptions are incorrect, please clarify in a comment and I'll update.
I'm assuming you have an application that:
stores sensitive data in a database stored in a DBMS installed on the workstation
is installed on a shared workstation
each user has their own login (non-admin)
allows different users to log on and interract with their data
user runs applicaiton which connects to a service
service connects with database, delivers data to users
service runs under its own user account
If this is correct, then you shouldn't have much issue.
The service can run under any account, but it would be easy enough to have it run under one of the standards (Local Machine or Network Service). Configure the database so that only this account can access it. In Sql Server, I'd only grant that user account (and admins on the box) login and access rights to the database.
This is the only security you need, if the users aren't admins. Now, when the frontend connects to the service, the user can provide the username/password and the service can authenticate against salted and hashed passwords stored in the database. All this is secure as long as 1) each user has their own login 2) communications are secure (using named pipes or SSL) and 3) no virii or keyloggers are running under an admin's credentials.
You can configure your service as to what account it runs under by running services.msc (or right-clicking on MyComputer and selecting Manage or clicking on Services under the Admin tools menu in Control Panel or probably in a number of different ways).
Bring up the list of services, right click on your app and hit Properties. From there, make it look like this: