ASPNetAuthentication -- where to find the minRequiredPasswordLength - c#

Having a bit of trouble getting this right...
The main objective is to have user configurable password strengths and here's where I get stuck:
There's a setting in some config file somewhere that specifies the minimum password length to be seven and I can't for the life of me find the blasted thing, I've checked the the app.config for the specific provider implementation, the web.config for the solution ( where the parameter is mentioned but set to 1), and I've even checked the .config files for anything even touching this but there's nothing. Kinda frustrating.

Well, the minRequiredPasswordLength is configured in your Membership provider section. Take a look at this question to see an example where it's set to 6.
Given that, you should access this value using the following property on the Membership type:
var minPassLength = System.Web.Security.Membership.MinRequiredPasswordLength;
If it doesn't work maybe you have a custom provider implementation that overrides the property value set in Web.config - see here for an example. In this case I'd suggest you do a search in your entire solution to find the string minRequiredPasswordLength and see from where this value is coming. If the custom provider comes from a third party DLL, you must have access to the library code to change that value.

Related

Is it possible for an Azure Role ConfigurationSetting to be optional?

My configuration code is setup in a way that default values are provided, and configuration files can be used to override these defaults.
For Azure Worker Roles I use the CloudConfigurationManager to read the configuration from the ServiceConfiguration.*.cscfg files for overriding the defaults.
A common reason for overriding the defaults is to provide different storage (blob,table,queue,etc) names during testing.
Unfortunately as far as I can tell, once a Setting has been defined in the ServiceDefinition.csdef file it must be provided in all ServiceConfiguration.*.cscfg files.
This wipes out the advantages of having less configuration to create and reducing the chance of errors creeping in while creating that configuration.
Is there a way to make a Setting optional?
Or is there another alternative place I can get deployment-specific configuration values from that works the way I want?

Can I track the use of ConfigurationManager settings

I am trying to clean up the web.config in multiple projects, but am worried that I may remove an appsetting/connectionstring that is being used somewhere.
For example, I want to know if ConfigurationManager.AppSettings["MySetting"]) is used.
I can of course do a global find for ConfigurationManager or Appsettings, but that doesn't check in compiled dlls (this project has some dlls referenced that i know are looking for certain keys).
I would love to be able to 'log' (text file, db, anywhere) the use of the .config file, minimally logging the key name, but ideally the namespace/method that called it. If this is possible, I could come back in some amount of time and check the log to see what is used.
Deleting the settings and seeing if the app throws an exception is tempting :), but not a realistic option.
Thanks in advance!
You can try to use aspect to log that a method was called.
I'm not sure if you will be able to get which configuration or key was retrieved but having all the places that's called is already a starting point.
Hope that helps.
Give a try for PostSharp or Unity.

C# custom configuration versioning

I have implemented a custom file configuration, that uses custom sections, using C#.
The main issue i have is with implementing some kind of version aware configuration loader.
Confgiurations change, but we need to make them usable anyway.
Is there any documentation that points in the direction of having some kind of versioning in configurations?
I'll give you two examples on what my issues are:
- key["key1"] changes from boolean type to int type.
- key["key2"] mandatory ceases to exist
thanks.
My tendency would be to add some kind of version header to the configs and keep a history of their schemas in the app. It could be troublesome in some ways, but at least you don't have to guess what an old value meant.
You could have the concept of default values for each setting. If you introduce a new setting and an old config file doesn't have it then it would use the default value. Similarly, if you remove a setting from the code then its existence in the config file would be harmless, it would just be ignored.
If you want to change how a given setting works (the type or the format) then it's a little more tricky. You could try to parse the value and if it's not in the right format you could ignore it and use the default value.

System.Configuration: Question on the Configuration.Save method

What is the difference between configuration.Save(ConfigurationSaveMode.Modified, true) and configuration.Save()?
Background: I have a programme, where I manipulate a web.config, which I use for configuring WCF Services. I load it into a Configuration object, change some attributes and save it back. When I use configuration.Save(ConfigurationSaveMode.Modified, true) I get an Exception like this:
"It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level..."
When I use configuration.Save(), then it works! The reason for the exception may be the section <serviceActivations> in my web.config (the exception points to this section)
The default parameters to Save are:
Save(ConfigurationSaveMode.Modified, false);
So the only difference would be that you force saving the configuration, even if it was unchanged. See http://msdn.microsoft.com/en-us/library/ms134089.aspx for more information.
Why woyld you write configuration.Save(ConfigurationSaveMode.Modified, true) when:
ConfigurationSaveMode.Modified means:
Causes only modified properties to
be written to the configuration file,
even when the value is the same as
the inherited value.
true means: true to save even if the
configuration was not modified;
otherwise, false.
Isn't the first option the opposite of the second?
ConfigurationSaveMode.Modified only saves the parts of the configuration that are different to the application/system configuration to a user local or roaming configuration (i.e. using ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel) with ConfigurationUserLevel.PerUserRoaming or ConfigurationUserLevel.PerUserRoamingAndLocal).
Since ASP.NET doesn't have user levels (and user isolated storage) this doesn't make sense.
From the documentation is not clear if any of the Configuration.Save overloads will really work in the case of ASP.NET which uses a completely different configuration setting inheritance model to non-ASP.NET .NET applications. In practice using one of the WebConfigurationManager to load the configuration manager is likely to be a necessary pre-condition to saving the file.
Another approach might be to explicitly load a explicitly designated file with ConfigurationManager.OpenMappedExeConfiguration.

.Net 3.5 DLL XML dependency

I wrote a class library in C# that uses a external XML file to store some data. I use this data (encoded rules) directly in the class library to do some substitutions within a text parser. The rules within the XML:
<rule>
<word>h e l l o</word>
<sub>Hello</sub>
</rule>
When I share the lib, I also have to share the XML. This is a bug source, at least for me ;) My question: is there any common way to solve such issues? Should I use app.config instead?
Thanks for any hint and best regards!
Why not embed the XML within the dll?
As with every external configuration data i can be changed or missing. So your application (or library) has to deal with such circumstances.
This means:
For every missing value you have a default value (should be declared in your documentation)
Check every value for correctness (type, range, etc.) (All input is evil!)
Blame user for invalid config files (error message, etc)
Implement and document behaviour in error case (abort, crash, use default value, etc)
So it doesn't matter which way to go, cause it is a user configuration (which means it can be changed by the user) and so you have to check those entries.
Create the XML file with default settings/values if it doesn´t exist.

Categories

Resources