I want to create a wipeout functionality for my windows store app so is there any way to uninstall Windows Store App programmatically in JavaScript ?
As others have already written, programmatic uninstall isn't available to Store-installed apps, by design.
That said, it sounds like the intention behind your question is that you want to offer your users a way to guarantee, for example, that any personal information is wiped from the device and perhaps also the cloud. Fortunately, because the app itself is the agent that would save any such data, you're also in control of clearing it out. Doing so would return the app to the state it was on first install.
Purging your appdata means the following:
Delete all files in the local and temp appdata folders.
Delete all local appdata settings in the settings container.
Clear out anything you put in the Windows.Storage.AccessCache.
Clear out any information you stored in the Windows.Storage.PasswordVault.
I didn't mention roaming appdata files and settings for a reason. If you use roaming appdata, that data will be automatically retained in the cloud for some period of time even if all instances of the app on a user's devices are uninstalled. This is done by design so if a user happens to uninstall all instances of the all and then reinstall within about a month, their settings and data are still there. (Imagine cleaning off a laptop and a tablet so you can sell those, and then getting some new ones.)
The upshot of this is that if you want to guarantee that data is wiped, then avoid using roaming appdata altogether. If you want to roam, then use another cloud service over which you have more control (e.g. tables in an Azure Mobile Service). This way you can specifically clear out all the data on user request.
By doing all this, then you're able to give the user a way to clear everything out just short of uninstalling the app, leaving the app in a clean state and protecting any sensitive information.
As an aside, you might be interested in this blog post of mine on the Windows Dev Blog, http://blogs.windows.com/buildingapps/2014/06/19/common-questions-and-answers-about-files-and-app-data-part-1-app-data/, and also the talk I did at //build 2013 called "The Story of State," http://channel9.msdn.com/Events/Build/2013/3-9118.
No. Neither in C# or C++.
And frankly I don't understand why one would need that when a user can uninstall the app from the start screen.
This is not possible because the user should always be in control.
Related
Sharing cookies from the browser to the electron app
I log in to my website. Then I start my electron application. I don't want to log in. I need cookies or tokens to log in. Is it possible to share cookies from the browser to the electron app?
Think about this from a security perspective: If any app could read any of the Browser's cookies, then it would be simple to spy on users or impersonate them from the outside (a malicious app, like spyware or something similar). So the answer is "maybe".
Firefox, for example, stores the cookies (assuming that you have not set a primary password for your profile) in an SQLite database in a well-defined folder. So you could definitely try to read them.
However, AFAIK most antivirus software is aware that this is a security problem and will thus nuke any app other than the browser which tries to access them.
So, as long as no antivirus software is installed and Firefox is used without a primary password, you "should be good".
However, this is not a good idea, even from a user perspective: The connection between "I logged in via my browser" and "I am logged in in the app" is not intuitively clear. Also, some (most) users may consider this a breach of trust. After all, if you read their cookies, what else will you read? Who guarantees that you only use the cookies from your particular webpage? An app "randomly" reading your cookies is kind of creepy if you think about it.
Then there's another hurdle to overcome: How do you decide which of the multiple browsers installed on the system (and even if uninstalled, there probably will still be the users' profiles left) is the "right" one? What do you do if multiple browsers have multiple session cookies for your webpage? All this is not as easy as it might seem in the first place.
I suggest you to look into some other technologies, like OAuth2, which may reduce the "login process" inside your app to a single click in case there's a session open for the device. How this is implemented specifically is out of scope for this answer (and hard to explain and understand without the required basic knowledge).
I'm currently working on a planning app, and I've ran into an issue. I can't find a way to store data without it being lost after restarting the app. I've tried cookies, window.name (despite the fact that that shouldn't even work to begin with), but neither of those work. The tasks (planned tasks) will be stored on the server, but seeing it's per person, having in input field for login everytime you start the app doesn't seem like the best plan. Any suggestions?
I have two Bokeh apps (on Ubuntu \ Supervisor \ Nginx), one that's a dashboard containing a Google map and another that's an account search tool. I'd like to be able to click a point in the Google map (representing a customer) and have the account search tool open with info from the the point.
My problem is that I don't know how to get the data from A to B in the current framework. My ideas at the moment:
Have an event handler for the click and have it both save a cookie and open the account web page. Then, have some sort of js that can read the cookie and load the account.
Throw my hands up, try to put both apps together and just find a way to pass it in the back end.
The cookies idea might work fine. There are a few other possibilities for sharing data:
a database (e.g. redis or something else, that can trigger async events that the app can respond to)
direct communication between the apps (e.g. with zeromq or similiar) The Dask dashboard uses this kind of communication between remote workers and a bokeh server.
files and timestamp monitoring if there is a shared filesystem (not great, but sometimes workable in very simple cases)
Alternatively if you can run both apps on the same single server (even though they are separate apps) then you could probably communicate by updating some mutable object in a module that both apps import. But this would not work in a scale-out scenario with more than one Bokeh server running.
Any/all of these somewhat advanced usages, an working example would make a great contribution for the docs so that others can use them to learn from.
I realize this might not be a best fit for SO, so please tell me where I should move/post this if that is the case.
My idea is after a user signs into the system, store the user preferences on the client in the form of cookies. If a user modifies said preferences, update the cookies. I need to do this because some of the preferences are client related and will need to be looked at via JavaScript.
I realize I'll need the preferences stored on the server as well. Just wanting to know if pulling them down into cookies is a good idea. My app is primarily ajax driven so I'd like to pull the preferences down once and just store them. I don't want to push them with each server request.
I'd like to avoid things like Local Storage so that I don't have to worry about browsers as much. Cookies seem to be supported heavily by all browsers.
Anyone concur or have a better way?
EDIT now that you've changed the question from when we first wrote answers:
If you are storing the preference data on the server, then there is no reason to keep preferences data on the local user's computer between visits As such there is no reason to put the data in a cookie as it just increases the size of every client/server roundtrip and takes storage on the client computer necessarily.
Instead, I would suggest that you simply put a preferences object in the page's javascript like this:
var userPref = {theme: "fun", permitContact: false, lastDisplay: "threaded"};
Then, you can get access to the preference values via javascript from any page with code like this:
if (userPref.lastDisplay == "threaded") {
// do something
}
Old answer before the question was edited:
If you want the client preferences to work from different browsers that the client might use, then you should store the preferences on your server (highly recommended). You can make them available in the web page at any time, by just including a small amount of javascript in each page that sets the properties of a preferences object to the value of the user's preferences. And, then you can have a preferences page where the user can modify/update the preferences and store the newly changed prefs back on the server again.
Cookies are for temporal state that may get cleared at any time and will only ever work on that particular computer. Plus, if you use cookies and if userA logs out and userB logs in on the same computer, the preferences will be wrong for userB.
Generally cookies are a good idea, provided that you don't have to store a lot of data. Just few things to keep in mind when using cookies to store stuff:
user can edit the preferences by hand so make sure you don't have things like is_root=false without additional server side checks.
this can be annoying when user removes cookies and preferences are gone, I would go for a server side preferences storage mirrored to cookies so JavaScript can use them.
Other possibility would be to serve dynamic JavaScript, with inlined preferences, instead of static files - you could serve JavaScript the same as you serve dynamic HTML, but then you have to be careful with caching.
You'll need to store the preferences on the server either way, as you don't want to trouble your user with having to re-create their personal settings every time they sign on with a different computer.
Just store them serverside.
I have an HTML5 app which is capable of running offline. However, I need to password protect the directory this app resides in to only allow access to authorized users. Initially I was using a PHP login page which set a cookie (outside of the app directory) then redirected to the app directory. The app (JavaScript) checks for the cookie and if it's there it lets the user run the app. If not, it redirects them back out of the app directory.
The problem with this method is that all of the files in the directory are still accessible if referenced directly (which I don't want). I do not want users to have to authenticate every time they hit the directory (it's a one-time authentication process; the cookie is there so that they never have to type their username/password again), and I also want to have a stylized login form (i.e. not using the default browser login box for http authentication).
Finally, because this is an offline HTML5 app, I can't include any PHP code in the app itself.
Any suggestions?
That doesn't sound like something you could do from Javascript. The script would need access to the file system to be able to restrict access to the folder, wouldn't it?
Unless this feature is exposed by the browser via a javascript API, I don't think it will be possible. It sounds like it would be a useful feature though.
Perhaps you could encrypt vital data, but apart from slowing down the application, I'm not sure what good it would do, since all the necessary keys would have to be stored locally as well...
Since the general rule of security on the web is that you can never ever rely on anything that happens client-side (e.g. in Javascript) without a double check on the server-side, this will of course pose a problem when the app is running offline and the server-side is not available :(
Looking at the "make Javascript redirect if the cookie exists" problem, unless I'm mistaken, it would be trivial for a malicious user to edit the Javascript, using for example Firebug, to redirect in any case.
EDIT: By the way, what level of security are you looking for? The "mom won't be able to accidentally access my account"-level (which it sounds like you already achieved), or the "no one, except maybe the NSA, should be able to hack it"-level?