Is anybody knows how to share cookies between 2 windows users?
I have a Windows 10, where have 2 users: one is admin and second is operator.
Admin is logged in into the system and then goes to the web site, where setup some config. In this config we have some specific value which should be store locally in machine and operator shouldn't know nothing about it. So he is set some kookie { someKey: someValue } and then log out from Windows.
After this operator log in into Windows and open the same website and he should have access to this cookie { someKey: someValue }.
I search around we and found nothing about it. Found only solutions about save to file system, send via tokens and save MAC address with a value into DB. But this is not suitable for me. I know that share cookies and store locally isn't secure, but need to implement that feature.
Web project based on chrome browser, asp.net mvc, angularjs and ms sql for db storage. Is anybody can help me with this issue about cookies?
There is no way to do this. First, every browser has its own way to store and retrieve cookies. It is impossible to write something that will work for any platform and any version.
Second, there is security. You can't just copy some files and expect this to work. Browser developers aren't stupid to leave such a big security loophole in their software.
You are mixing Windows applications with full control over the system with a web application that only resides within the browser. You should find a better way. You could use a certificate installed on the machine to validate the user, but it seems to me there are better options, like simply logging in, etc.
Cookies are a browser component that all major browsers locate in user specific directories. if you could change it to HTML5 storage API and you could setup the storage to a folder both users have access (dunno about this). You could have client side shared data. Most probably, you could not. And certainly not using cookies.
Disclaimer: I havent used storage API
Edit: Just checked. Storage API does store the data un user specific folders, so cannot use it either.
"In practice, "client-side storage" means data is passed to the browser's storage API, which saves it on the local device in the same area as it stores other user-specific information, e.g. preferences and cache. Beyond saving data, the APIs let you retrieve data, and in some cases, perform searches and batch manipulations." Source: https://www.html5rocks.com/en/tutorials/offline/storage/
Related
I have a single solution with multiple C# ASP.NET Web Forms projects. I want a way to identify a given browser so that each website can identifier that same browser. I need to do this from the C# Code-Behind code (not with the client code, like JavaScript). I also cannot use the Session because it isn't shared across websites. I don't think cookies are either.
For example, if a user logs onto Website1 and then logs onto Website2 with the same browser on the same computer, I want to be able to identify that. But if a user logs onto Website1 with Chrome and then Website1 with FireFox (regardless of whether it's on the same computer or not), I want to detect that as well.
If it makes any difference, I am using Azure to publish my web projects. So all websites will have similar domains (eg website1.azurewebsites.net and website2.azurewebsites.net).
If you want to track someone using the same browser on the same computer then use a cookie. If the websites have different domains you'll need to be clever because modern browsers have a lot of protection against what they see as tracking cookies. One option is using a hidden interstitial page as described here.
Your second scenario, a user accessing same site with different browsers, I suggest storing the user agent string (one of the request headers) and adding this to a login audit so you can build up a collection of different user agents used by a given user. There are libraries available for parsing user agent strings and extracting name, version, engine etc.
Between these two techniques and a bit of business logic you should get what you need. If you would like me to clarify any of this, let me know and I'll provide more detail.
We have a developer debugging tool to help manipulate security section of a database that our product depends on. This tool's purpose is to inject state into database to reduce time to create test scenarios. The database is not typical database that one can manipulate using sql. Rather it is a binary file that only our tool can manipulate. This is a C# application.
If this tool goes outside our company (say someone emailed it to a customer who shared it somewhere public), that could open lot of security issues.
We like to build intelligence into this tool so that it is usable within company or at partners network with whom we shared the tool. We have no knowledge of partner's network.
I am wondering what the suggested ways of implementing it?
Like:
Ping company active directory server or exchange server. Allow the tool usage if you can reach one of these servers.
Package a certificate with the tool that expires a month from build date. Always check if the cert expired or not before allowing usage of the tool.
Modification of (2). Make every user to request a key to unlock the tool after specific date.
Before we go implement a solution, I am wondering if there is already a library that does this.
Thanks
Assuming you host "file" inside your organization and all parties just access it somehow. If you give both data and tools to modify it to external partners there is nothing really to stop them to modify data as they pleased (short of legal/administrative actions but that is outside of SO scope).
There is also really not much you can do to protect code running on user's machine irrespective if it is C# or native compiled code. .Net code is a bit easier to modify/bypass protections but if you concerned about securing access to a file you need to protect files/servers rather than worry about client side code.
Usual solution to such problem - authentication and authorization: only allow authenticated users to access the file and only accept changes from authorized users.
If you use file based storage than inside your organization regular Windows domain accounts would work for authentication and regular file system permissions would work for authorization.
For outside partners you probably would need server to perform modification of the file(s) and authentication/authorization possibly using ADFS or Oauth.
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.
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)
I've been working on implementing an api in c#. The implementation is going well, but I did come across a concern.
When my library has authorized against the api I have a auth_token which I use for consequent queries to the webservice.
The token needs to be kept between program runs as it stays the same for the user (although I do check if it is still valid when the application starts).
For testing purposes I basically just save the token into a text file which is kept in the root directory of the app.
This works fine, but is this the best way?
Not sure the user will appreciate that it gets saved in a cleartext file (even if it is on his own pc).
So, what is general practice for saving tokens like this?
I would use the Windows Data Protection There are numerous examples around on how to use it from C#. It uses a user specific key to encrypt the data. Only the user themselves can decrypt it. Also be sure to secure the data during transmission between the server and the client.
Create a settings file for your project in the project properties, add a AuthToken property to the known settings (probably at the user level), then use:
Properties.Settings.Default.AuthToken = userAuthToken;
If you think they'll want it hidden, encrypt or encode the userAuthToken so it is less obvious.
You can verify if the api is used under asp.net or windows environment ( it's enough to check if Request is null) and on the first case use a cookie, on the latter save it on a registry key.
That may work in a local app or running the CI locally, but if you are in DevOps (Azure) your test app will reside in your VM bin folder. After every deployment your bin folder gets wiped out so the token you saved in your bin files is gone. Perhaps the best way to save it will be encrypted in one of your DevOps environment variables in your release pipeline so you don't loose it. When running locally you can save it anywhere.