My application is hosted on IIS 7.0. There is a scenario where end user save the image (from my application) into his/her machine. Now my question is can we make a default folder in end user machine so that every time when user save the image , it will automatically save on the default folder location that we have created from our application. And please let me know how to create the folder in client system.
Please suggest me. Thanks in advance
No, this is impossible.
(At least under standard security conditions. If you limit your users to, for example, Internet Explorer on systems with your custom written signed ActiveX control, then it might become possible)
Related
I have multiple windows store apps of a company and all of them have signing in option. What I am trying to do is create a mutual login system for all of my apps. In simple words, If user log into one app then he automatically signed in other apps.
I am using sqlite locally to maintain user's session data. So, I tried to access the one App sqlite file from other app by giving a static path to its installed location. But it won't open the sqlite file.
Can I put this sqlite file in any folder where other apps can access it too?
Is there any common folder/storage space in windows store app where other apps will be able to access this sqlite file?
Any help would be really appreciated, Thanks in Advance!
Although it doesn't help right now, Windows 10 does have a solution for apps from the same publisher sharing data. You can use ApplicationData.GetPublisherCacheFolder(folderName) to get access to one or more folders that you share amongst your apps.
As far as I know there is no common storage between apps. The best you can do is to store the sqlite file somewhere locally (let the user choose) and then hold permission to access that file in the MostRecentlyUsedList
This will allow your app to access it at any time. However, the user will have to manually open the file at least once with each app that needs to use the login.
The only way I can think of to do what you're trying to do without user interaction would be to write your own server backend and use the IP address / user agent string and other variables to uniquely identify a device. When the device logs in then all other requests from that device would be considered "logged in" until the user logs out from one of them.
This would be very insecure and I would not recommend it. Anyone could impersonate the user if they knew enough about the device they were using, and were behind the same router.
I am trying to put some files and folders in a place that my WinRT application could access and read files from. These files and folders must be locked and permanent even when I uninstall the application.
There are 4 main categories of folders that you have access to from a Windows Store Application:
/AppData/Local/<yourpackage>
Standard available libraries (Music, Pictures, Videos)
Libraries that require elevated permissions (Documents)
User-defined folders (through a FilePicker)
Typically you will store data specific to your application in the first kind and data for the user in a library or a user-defined folder.
When your application is uninstalled, its package folder under /AppData/Local is removed so there is nothing left there (note that this contains the directories which you get using ApplicationData.Current.Local and ApplicationData.Current.Roaming).
Therefore in order to save data persistent through installations you will have to save them in a different directory. Note however that in the case of option 4, the user might not decide to give you access to the folder he picked out the previous time or that he doesn't want to give the application access to the Documents library.
I think a more solid solution would be to save the data on a remote location so that the user can download it when he installs the application again, rather than relying on everything being saved at the user's device.
With regards to the locking: you could look into the DataProtectionProvider and see if that suits your needs.
To reiterate Jeroen's response:
To save data locally in a place that won't be deleted when the app is uninstalled, you must use the file picker to have the user choose a location.
Saving the data remotely is the only option that doesn't require user interaction.
It's possible to save data in the app's roaming settings, as those are retained for some period of time after the app is uninstalled. If the user has the app installed elsewhere, that data will be retained continuously. If there are no other installations, it will be retained for around a month.
I recently wrote a blog post addressing this exact scenario in more detail, including how to get a persistent user identity for any data your store remotely: http://www.kraigbrockschmidt.com/2014/07/31/persisting-data-after-uninstall/.
I use the following code to build a desired path for an XML file:
System.Environment.GetFolderPath(System.Environment.SpecialFolder.ApplicationData);
When executed from a Windows Forms application, it returns:
C:\Users\MyUsername\AppData\Roaming\...\Database.xml
When executed from within a Windows Service, it returns:
C:\Windows\system32\config\systemprofile\AppData\Roaming\...\Database.xml
I am now resorting to having a custom installer action persist the path in a registry key since the custom action will have a desktop context. If there is a better approach, please let me know.
What I am really interested in finding out is why the behavior is different in the first place. The Windows Service in question is set up to use the LocalSystem account in case that matters.
Only you know what the specific requirements are for this folder, but if it's to share data between multiple users, ApplicationData is the wrong choice:
The directory that serves as a common repository for application-specific data for the current roaming user.
A roaming user works on more than one computer on a network. A roaming user's profile is kept on a server on the network and is loaded onto a system when the user logs on
See the SpecialFolder enumeration and pick an appropriate value that fits your requirements - one that doesn't depend on a specific user. Most of these start with Common.
I suggest that you should check and make sure that two apps are running by the same user.
I tested your code in both winform app and webservice app, but their values are the same, so I can't find your real problem.
good luck!
Ok I know this is a probably a very basic question but I'm more of a winform person.
Question is simple.
If we Add System.IO to a Web Form . Can we then use a StreamWriter to write a log file to the end user Computer?
For example if page_Load use the following code:
StreamWriter sr=New StreamWriter("C:\abc.log)
sr.Write("ABC")
Then where this abc.log file is created? on webserver or on end user? If on websever then how can we write it on the end user machine?
I want to write a log file on the client machine. What are options? Is using a cookie an option?
No - that is not the way the web works...
You could present the Log as an download, that would be the cleanest solution.
As everyone in this thread has pointed out: this is simply not possible. Now depending on what you are trying to store you could leverage cookies to store some information on the users computer but this can be cumbersome and you are limited to 4K of information. That being said HTML5 offers the new JavaScript objects localStorage and sessionStorage which are basically a key/value dictionaries. localStorage would probably suit your needs best I think since it will persist information on the users PC after the browser is closed. For example:
function logSomeData(message) {
localStorage.logFile += message;
}
function showData() {
alert(localStorage.logFile);
}
If you run the logSomeData function in a browser, close the browser, then come back and run the showData() function the value you added to logFile will be persisted. This isn't a new concept, this is doing exactly what cookies do today except that localStorage is easier to work with (in my opinion) and it can store much more information (2MB to 10MB depending on the browser). It is worth pointing out that this is a new technology so older browsers like IE7 can't use localStorage.
Please let me know if you have any other questions!
As far my knowledge you can't write the client file using asp.net.
In your example you are writing the file where application is hosted.
Means the application server's c:\abc.log
All the code behind in asp.net runs on the server so the code you posted will write to the server machine.
Browsers don't allow interaction with the local machine file system for security reasons
You could use some other technology (e.g. an ActiveX control hosted in a web page)
why you want log file on client site ?
if you want to store some information on client site use cookies
If you're stuck to Internet Explorer 6, the only solution to be able to store client-side data, is to use userData Behavior. It well let you store up to 128kb.
I would recommend you to have a look at jStorage. Which is:
a cross-browser key-value store database to store data locally in the
browser - jStorage supports all major browsers, both in desktop (yes -
even Internet Explorer 6) and in mobile.
It's mainly based on HTML5 localstorage but it will switch to any available technology (like userData Behavior) when HTML5 is not supported.
You could download the text file of log to client machine if you flush the .txt file in the respose object i,e (response.write)
Lets say we have photographers who use one computer in a department. They take pictures of an event then upload and organize pictures in an application. That application by default takes someone's shared location and copies pictures to that share.
On a web server there is a share we point it to. We want to make it so ONLY that application can access that share, and only THAT web application (of course, anyone with admin login to the physical server can).
Also make it so that any web browser can display the image (I believe Firefox can't take a file location of \\server\share)
Logically it would look like this:
Photographer uses an application on a public computer
Application copies images to share
Web application uses images (cross browser)
No user from public computer can access those images EDIT: the displaying on the webpage is not the problem, its how I store files in the webroot securely, so that my app can SHOW the images that are located within a shared location in a webroot. Allowing only the application on a terminal computer to access that share and NOT the user running the application from that computer. I.e. a person cant just run a command and download the entire directory contents from wherever he wants.
Wait, what? You want to show the users some pictures in a browser, but don't allow them to download them? That's impossible.
Simply configure your share's permissions (ie right click on it) to be limited to a certain windows user. Run your application under that windows user so it will have access to that share. Done!
Create a service account and run/impersonate your web and desktop applications with the
service account
Share the pictures (located on the shared drive) for the service account so that no other
user can access