I have an windows application (WPF) in which we are running on each login, however when the user first logs into a new PC the application will need to do some specific tasks, but only on the users first login and never on subsequent times.
Is there a way in .Net 3.5 to query wether the user has logged in before (ie some kind of login count)?
Failing any native support I will create a txt file in the users registry however I wanted to know if there is a native way of achieving this first.
We use redirected folders so the user may have already logged into a PC on our network these special events should only occur when the user hasnt logged in onto the PC and Windows has had to create a new profile for the user on the PC.
If I am not clearly explaining what I am seeking, please dont hesiate in letting me know.
Matt
Failing any native support I will create a txt file in the users registry however I wanted to know if there is a native way of achieving this first.
I'd recommend going with this option. Don't try to detect it, just create your own state on first run.
I suggest this, not because it is technically impossible to achieve the functionality you describe, but because it is a better user experience. It provides an easy way to re-do the action without having to recreate the user.
... a txt file in the users registry ...
I'm not sure what this means. You can create text files under the user's profile directory, and you can insert string values in the registry (but not files of any sort).
As for the particular mechanism, I suggest you consider:
An App.Config value. Clearing out the value is easier to support or batch-script than a registry value, and makes the user less scared that their machine will explode if you have to tell them to edit the settings. Users are scared of the registry.
A sentinel text file under the user profile directory. Wiping out the file is super-easy to support and batch-script. Instead of editing a text file, they can just delete one. But this makes it so you have multiple config mechanisms, so multiple points of failure. I'd only do this if I were using the App.Config for additional settings in the program and thought the user wouldn't be technical enough to hand edit it.
The windows registry. Remote registry access might be easier than remote file access, if you're having to do remote troubleshooting. It also might be easier to mess with via group policy, in case this is an intranet app and you need to force a re-run on all machines in your org.
I'd carefully consider my options and which is most likely to ease support (be understandable by my users) before committing to one. I'd also consider the remote-troubleshooting/remote reset scenario.
This may not be what you're looking for but I'm hoping it will help you anyway.. I do not know from the top of my head how to do this in WPF but I do know you can use an "unattend.xml" file and the FirstLogonCommands to execute a script or application on first logon. I have used this for Windows 7, it may not apply to XP.
Related
I have a winforms application that connects to a database with a connection string and a generic user
"Database=DBADAS;Server=TMT123\\SQLEXPRESS;User ID=user; Password=*****;
After connecting into the database with a login dialog, we check if the user and password are existent in the user table from the database.
My question is now if this is a good practice? because basically in the connection string there is every information needed to crack the server.
There are a few ways to go about this safely. Since it's a Winforms app and not a web application, most of your security risks involve someone already in your network peeking at the connection string. This adds a layer of security in and of itself.
1. Hardcoded
You can hardcode the connection string that fetches the users into a DLL and make your application depend on that DLL. I only suggest this because it sounds like the "generic user" password is permanent; otherwise, you'd have to recompile code every time you changed the password, then deploy again. This is very secure, however, as the value isn't stored in plain text.
2. App.Config
You can stick it in a configuration file. Within a secured network, this is probably the most versatile option, as you can store multiple strings and easily update them without updating the full application. This goes well alongside settings like a "DebugMode" setting, etc. Using App.Config or another XML file is ideal, but you can roll a quick and dirty .txt file, too.
3. Database
Probably the most secure way of all, as you can encrypt your database and code your programs to fetch their connection strings and login information from that database by using an unrelated login. This allows greater control over what can be reached by the application when a user has not yet logged in. It also prevents the software from operating outside of the network, which may be desirable.
4. Internal API
Having a separate application serve this data divorces user capability from your concerns, as the API and your app can exchange verification keys to see if your app even has permission to try to connect. This is my personal favorite, but obviously the most work to set up.
5. Registry Entry
Depending on how you have this installed, it may work well to embed the tokens you need in the Registry. This guarantees the app requires admin permissions to install, and allows you to use Windows security to restrict access to the hive.
Again, since it's an internal non-web app, I wouldn't worry too much about the plain text of the connectionstring; if someone has gotten this far into your network, chances are you have much bigger problems already. I wouldn't leave it floating as a plain text file in a local directory, but any degree of security above that is probably acceptable for your purposes.
Encrypting Web.Config
Open Command Prompt with Administrator privileges
At the CommandPrompt, enter:
cd C:\Windows\Microsoft.NET\Framework\v4.0.30319
In case your web Config is located in "D:\Articles\EncryptWebConfig" directory path, then enter the following to encrypt the ConnectionString:
ASPNET_REGIIS -pef "connectionStrings" "D:\Articles\EncryptWebConfig"
Use Aspnet_regiis.exe tool with the –pef option and specify the application path as shown above.
Note: The parameter "connectionStrings" is case sensitive.
For Winforms: You need to rename your app.config to web.config encrypt it by using steps 1 to 3 and again rename it to app.config.
Reference: https://www.codeproject.com/Tips/795135/Encrypt-ConnectionString-in-Web-Config
I am in the process of writing an offline-capable smartclient that will have syncing capability back to the main backend when a connection can be made. As a side note, I considered the Microsoft Sync Framework but since I'm really only going one-way I didn't feel it would buy me enough to justify it.
The question I have is related to SQLite vs. SQLCE and ClickOnce deployments. I've dealt with SQLite before (impressive little tool) and I've dealt with ClickOnce, but never together. If I setup an installer for my app via ClickOnce, how do I ensure during upgrades the local database doesn't get wiped out? Is it possible to upgrade the database (table structure, etc. if necessary) as part of the installer? Or is it better to use SQLCE for something like this? I definitely don't want to go the route of installing SQL Express or anything as the overhead would be far too high for what I am doing.
I can't speak about SQLLite, having never deployed it, but I do have some info about SQLCE.
First, you don't have to deploy it as a prerequisite. You can just include the dll's in your project. You can check this article which explains how. This gives you finite control over what version is being used, and you don't have to deal with installing it per se.
Second, I don't recommend that you deploy the database as a data file and let ClickOnce manage it. When you change that file, ClickOnce will publish it again and put it in the data directory. Then it will take the previous one and put it in the \pre subfolder, and if you have no code to handle that, your user will lose his data. So if you open the database file to look at the table structure, you might be unpleasantly surprised to get a phone call from your user about the data being gone.
If you need to retain the data between updates, I recommend you move the database to the [LocalApplicationData] folder the first time the application runs, and reference it there. Then if you need to do any updates to the structure, you can do them programmatically and control when they happen. This article explains how to do this and why.
The other advantage to putting the data in LocalApplicationData is that if the user has a problem and has to uninstall and reinstall the application, his data is retained.
Regardless of the embedded database you choose your database file (.sqlite or .sdf) will be a part of your project so you will be able to use "Build Action" and "Copy to Output Directory" properties of that file to control what happens with the file during the install/update.
If you choose "Do not copy" it will not copy the database file and if you choose "Copy if newer" it will only copy if you have a new version of your database file.
You will need to experiment a little but by using these two properties you can have full control of how and when your database file is deployed/updated...
I have a page on an intraweb (that I didn't create) which allows a user to specify a .txt file and then it writes the results of a SQL stored procedure to the file using StreamWriter.
It apparently stopped working for some of my workstations several months ago, so I can't trace it to any specific changes (However, I know the code itself didn't change).
If I access & use the page on the server (where the wwwroot and applicable database are located), it successfully writes the .txt, whether I specified a local file or on a workstation on the network. Users on some workstations,though, are no longer able to write to a file.
(It is also not just writing a blank file. The "Date Modified" remains unchanged.)
The problem seems to be machine-related rather than user-related, as I can login as the same user on different workstations with different results.
I still think it may have something to do with permissions, so I created a .txt on a problem workstation with every possible account having full permissions, but no luck. Permissions on the database, stored procedure, and folder destination seem correct.
Any suggestions welcome, Thanks.
You mean to tell us that the page completes with success, your calls to StreamWriter all succeed, and yet in the end there is no file? I find that really hard to digest. A much more likely hypothesis is that the page fails and exception is thrown. Such an exception would be logged normally in the system event log.
From the description of your symptoms the issue could be a constrained delegation scenario: the page is impersonating the IE user and it cannot flow the credentials to whe accessing the network resource.
It turned out to be the IE security setting "Include local directory when uploading files to a server". This setting is disabled by default.
The working PCs had the setting enabled for some reason. Adding the site as a "Trusted Site" also enables the setting, achieving the same result.
Does anyone else think Silverlight 4 security is a bit screwball?
Look at the following scenario:
Silverlight when set to trusted app, and run out of browser mode allows you to browse for a file using the file open dialog.
You require the name of the path of the file to open it up from any COM automation. For example (excel/word) but this could be anything.
It is impossible to get the full path of the file from the dialog because of security restrictions
You can however using COM FileSystemObject - do what ever you want to the users file system, including create folders, move and delete files.
So in other words, why all the fuss about security in Silverlight, which actually hinders real business use cases, when its possible to access any file anyways using COM?
To say it another way, if a user runs a malicious silverlight app, its unlikely they'll say - oh well it was COM at fault. The COM was afterall being called by a Silverlight app.
Here is what I mean....
User browses for file - c:\myFile.xls
Silverlight prevents you from getting the path (for security reasons)
Silverlight only lets you work with my documents
Using COM you can do what ever you want to the file system in the background anyways. Including copying that file now to my documents, if only you knew the name! But besides that you can wipe any file potentially if its not in use.
In my opinion Silverlight security model is flawed, either they should have given developers full trust and allow us to run apps as if they were running locally
or
Not allowed Silverlight to access COM.
Is it just me, or can anyone else see that its a bad implementation?
This triggers security alerts:
OpenFileDialog flDialog = new OpenFileDialog();
FileInfo fs = flDialog.File;
string fileName = fs.FullName;
This doesn't
dynamic fileSystem = AutomationFactory.CreateObject("Scripting.FileSystemObject");
fileSystem.CopyFile(anyFileName,anyDestination);
I don't agree with your point of view. The fact that you can do pretty much anything that an installed COM object will allow you to do is not a reason to modify a whole bunch of existing Silverlight code to allow you to do those same things.
Why? Because in the process of opening up that code there is also an increase chance that in some unintended way that same code could get run when the Silverlight component is not running in trusted mode. If that were to happen even once the media would all over it in a shot and Silverlight's reputation would, probably unfairly, be in tatters.
Personally I'm quite happy with the very cautious approach to security that MS are taking with Silverlight.
some Silverlight controls such as the OpenFileDialog work in both trusted and untrusted mode. These controls have been ported from previous versions of Silverlight where the new levels are elevated trust were not a consideration.
Thank you to Anthony for pointing this out.
Developers need to be aware of the definition of trust we are discussing here. Running a Silverlight application in full trust with elevated privileges IS NOT the same thing as running a local Silverlight Windows based Application. It is also far more restrictive than ActiveX.
Its possible that the trust here provided in Silverlight suits your particular business requirement. It is however likely that there are scenarios where you will find Silverlight too restrictive, its best to do your research upfront, and run code samples to ensure you can do the critical stuff, before jumping in head over heels.
Microsoft guarantees that public Silverlight API has the same behavior for both for Windows and MacOS platforms. So the functionality is many ways limited by the common denominator and technical feasibility. Please treat COM introp as a specific case addressing only Windows platform and only in full trust mode and it is not going to work the same for other platforms. So the security restrictions are valid as they are the same for both worlds in terms of API reuse.
I agree with the original poster. I think it's bad implementation. We are given a built in dialog to browse for a file, including directory structure. We can select a file and get a FileInfo object, but security prevents us from getting the FullName (directory and file name). Why? How does that improve security? What's the point of the open file dialog to begin with?
And as the original poster mentioned, with those dynamic objects, we can modify the local file system... which seems like the possible security hole.
All I want to do is read some data from an excel file... a way for my users to import excel data into the application, and the file could be saved anywhere on their machine. These are sales reps using an excel files to record orders locally until they can get to an internet connection. Who knows where they all save that file... so I'm not going to try to suggest we tell them all to store it in the same place in "my documents". I'll get laughed at if I suggest that.
It seems like it should be incredibly simple. But that "security measure" that keeps us from getting the directory the user chose from the built in open file dialog makes it so that we can't use the dialog for the purpose it was created for.
So what's the alternative? Is there a way to pick files using those dynamic objects? Do I have to write my own file selection tool using those objects that can modify the file system? Since I don't need anything but to read the file, and because I read something somewhere that we do have access to the file stream... is there a way to using the file stream to open up the file for reading using the AutomationFactory?
I am looking at writing a silverlight app that I plan to use OOB setting to enable use on both PC and mac.
I have been doing a little investagation on the isolationstoragefile and what I understand is it will work for both pc and mac without a problem.....Is that correct?
The application I am building is going to be a business application that will submit details back to the main database if there is an available connection. If not then I want to store the information locally until there is an available connection.
My question is lets say I have 3 user accounts using the same machine. Can I have the isolationfile stored in the same place? or must it be under the user profile?
I don't want to have orphaned records which I could see happening if the data is stored on each user's profile.
Any advise would be great!
I understand is it will work for both pc and mac without a problem.
That is correct. You don't need to worry about the mechanics of how it is persisted to disk.
I have 3 user accounts using the same machine. Can I have the isolationfile stored in the same place? or must it be under the user profile?
IS is located under the user profile. In a full trust (elevated) OOB app you may be able to store files elsewhere on the file system by using the FileSystemObject or by using some COM interop, but there is no guarantee that you can get to that file again (NOTE: i haven't played with saving files external to IS, so may be wrong/misinformed on this). If you can whack files out to anywhere on the file system you should be very careful doing it - what if you are running on a Mac?
I don't want to have orphaned records which I could see happening if the data is stored on each user's profile.
If you mean data may be stored locally because of no connection, then that user logs off and never logs back in again to that machine so their data never syncs to the server, then yes that is a possibility. Having a service monitoring for saved data files would be ideal, but you can't do that under SL. To completely eliminate that issue may take a change in your product, like writing it as a WPF client instead of SL.