ASP.NET Security Terms

ASP.NET Security Terms

Authentication - Determining identity.

Authorization - Determining the rights and restrictions associated with an identity.

Confidentiality - Ensuring data is accessible to only those authorized.

Custom Authentication - When the authentication is implemented without using one the standard authentications; Windows, Forms or Passport

Forms Based Authentication -

Impersonation - Executing code in the context of another identity.

Integrity - Ensuring data has not been changed in an unauthorized manner.

Passport Based Authentication - Authentication is handle by Passport

Role Based Authorization - Authorization that uses Roles or Groups as intermediaries in assigning rights and restrictions.

Windows Based Authentication - Credentials are verified against windows accounts. Where possible the windows integrated log in form is used.

Corpen Source

Clopen Source refers to Open Source projects that have adopted practices that Close off uses or rights. There is a special category of Clopen Source that feature a Corporate Entity like Sun, Microsoft, Novell or any large company, supporting the Open Source software. This blending of Corporate and Open Source software should be labeled as such as Corpen Source.

Novell is currently the corporate patron of the Mono project. Mono could be summarized as Dot Net Framework Everywhere. That is the making the Dot Net Framework available on non Windows OS but it will also be available on Windows. If Mono remains successful, this cross platform capacity would make it preferable to Microsoft's version. So one can see how Novell interest in this project and as the corporate sugar daddy it is clear Novell will call the shots. As such, Mono is a Corpen Source project.

Firefox which is spun out of Mozilla is a Corpen project of Mozilla. But in addition to this Google provides significant resources in exchange for access. The integration of Google search and antiphishing consolidates Firefox as a Clopen Source project.

In addition to Corpen Source there are Corpen Standards projects. Microsoft submitted C# before ISO and ECMA, but as Microsoft provides all the resources it is clear C# is a Clopen Standard. Sun started to submit Java to ISO and ECMA but withdrew and released large portions under the GNU GPL instead. No doubt this was an attempt to get Java accepted as an Open Standard while retaining control. Having failed this they made Java into a Clopen Source project.

Clopen Source

The promise of Open Source was Free Software.

Open Source takes it's name from the practice that the source code should be open in all senses. It should be Open for Inspection. It should be Open for Contributions and It should be Open for Repurposing for Alternate Uses.

But like the first communes and every commune since, it is broken up by questions of who owns what and who should decide. One piece of property that no open source project will surrender is their trademark. Trademark becomes the camels nose under the tent. Here the camel is asserting that the software is Closed for some purposes.

More of the Closed camel follows because there must be some entity to govern both the use of the property and development of the software. If no one became rich or famous, a minimal platonic democracy could have formed and it would somehow work. Now everyone has an eye on cashing in big on their Open Source project. Often the projects license have terms that allow the owners to take back the software.

The GNU License is another common closing. Because this license grows virally you must always be worried that the free software you use will ultimately cost you your software.

A minor variation of open source software closing are projects that require extensive signing over of rights. Fortunately the irritation factor has caused these project to wither.

The takeaway from all of this is every Open Source project has some significant Closed aspects to it. As such we should borrow a term from mathematics and label projects that are significantly closed as Clopen Source. And projects which use the GNU License or have take back provision should present themselves as Clopen Source projects.

Open Source's Infinite Budget: Part 2 Your Company

Open Source has an infinite budget

As I discussed in Part 1 The Community, the open source community is not the source of this infinite budget. In fact the Open Source projects are overrun with bugs and security breaches and as such are turning to various Clopen models to generate revenue. Most of the Clopen Source modes are failing. (The notable exceptions are using a variant of Clopen Source which can be called Corpen Source which I will address in another post.) So if the infinite budget is not in the community where is it?

If you have allowed a free reign of open source in your company then it is coming from you. And it is being spent in a way that should alarm you.

Suppose your company allows the use of any and all open source tools. To the developer this is functionally the equivalent of an infinite budget for open source tools and software.
Whenever the developer wants a tool it's purchase is automatically approved because the price "free" does not reduce any budget.

He then can start using the tool and all is well.

Provided of course that it stands alone and has no bugs or security problems. Oh and provided of course that he does not need to learn how to use it. But if it needs to be integrated or bugs need to fixed then the budget that pays for it is hidden from management.

The developer will be spending hours integrating or fixing or working around bugs. These hours come out of the finite number of developer hours available to you. Note there is no check or limit on how much effort will be spent on supporting open source in your company, as such the budget for open source that you are paying is infinite.

So what is the moral? Never use open source software?

No, the answer is harder than that. What is called for here is management. Management means monitoring and making some hard decisions based on facts. Some open source software, NUnit would be may favorite example, is almost defect free and can be easily used with little integration or learning ramp up time.
But keep an eye on these, even if you stick to solid open source software, the integration costs increase at a factorial rate as the number of components increase.

There will come a time when you should opt to use a development stack and pay a flat fee instead. MSDN is a great example. For a few hundred dollars a developer (partner pricing) you can get access to all the software needed and at the same time the integration costs disappear.

Backing Down A Bug

So a bug is found in production.

In spite of your following all the best practices.

You had separate environments for Development, Integration, QA (testing), UAT and Production.

You have been doing versioned releases and following your documented change control procedures.

You had a QA staff that did it's best to test for and find all bugs.

You have three levels of help desk or technical support.

And in spite of this a bug made it all the way out to production and it must be fixed. And the business side of the house is flipping out and the pressure is on. Fix the bug now!!

How you handle this will determine if your company grows and gets a tiny bit better. Or should you fail, you the company will plant the seeds of disruptive behavior that will haunt you for the rest of your tenure.

You must avoid the temptation to storm in and take things over. You need to Back This Bug Down From Production with the care you would back a jumper from a ledge.

First make sure that the help desk or technical support was engaged. If not, engage them. Use this as learning opportunity for the support staff to learn how to mitigate or work around bugs in production. Should you find a work around, you must insist to the suits that it is over. A work around has been found. The work around is in place. Both the bug and issue (the issue is how the bug made it to production) are being researched and will fixed in later release. End of Story. Do not be stampeded on this.

Now chances are good that a work around is not immediately found. In this case, the backing down starts. QA must take a role here. At this point QA has tested the application and their job is to get the bug reproduced in the QA environment. Again, you must resist the desire to jump in and take over. QA has an important role in defining the bug. If QA can reproduce the bug in the QA environment, you should then be able to use this information to reproduce the bug in the Development environment. When you have fixed bug, QA will now be in a position to test the fix. This would not be possible if you had ripped control away from Tech Support or QA.

But this is not the end of the story. There is still the open issue of how the bug survived your processes. Inevitably something is missing in terms of testing or the processes were not followed. Fixing this issue will prevent future bugs.

Open Source's Infinite Budget: Part 1 The Community

Functionally Open Source has an unlimited budget.

Open Source promoters rave about the legion of programmers that stand poised to squash any bug that emerges and the other legion diligently adding features and functionality that the suits would never allow in a corporate run development and yet another legion that will repair any security breach discovered. It would appear that there is a bottomless pit development resources for any Open Source project.

But despite this, Open Source projects are plagued with bugs and security failures. Boosterism on the part of the Open Source believers and antipathy (the contempt and aversion variety) on the part of Open Source skeptics has resulted in these defects receiving little coverage.

So let me refresh your memory with a few salient recent developments. In a head to head security test of the LAMP (Linux Apache MySql PHP) stack versus the Microsoft stack, the LAMP stack was breached first. Linus Torvalds has been quoted "Even by the most *stringent* reasonable rules, we add a new bug every four days." Linus is pleading for us to look past the bugs because of all the features they are adding. What he and other Open Projects are lacking is resources devoted to QA. But even if they had adequate QA there is an additional lack of desire in developers working for free to fix bugs. They would much rather implement some bright shiny object.

This lack has on the one hand caused Linus to threaten to halt all new development on the kernel so that the bugs must be fixed. And in the rest of the community we have seen numerous experiments in Clopening the software. (Clopen is a term borrowed from the mathematicians, it is possible for things like sets to be both closed and open in math, when this happens they joke that the set is clopen). The idea behind Clopening the Software is this will give the projects resources to get a handle on Architecture and QA as well as means of providing the maintenance to fix those bugs no one wants to work. Often the Clopen occurs by offering privileged access for those who pay a premium. The software projects are surprised to learn that there are few takers and in return for the small amount of revenue they want quite a bit of control.

Which leaves one to conclude that Open Source's Infinite Budget does not come from the community. In Part 2 Your Company, we will find the ugly truth.

C# Naming Conventions

No one C# naming convention has dominated development.
A few of the major forms are All-caps, Camel Casing, C-casing, Pascal Casing and Hungarian.

In fact Microsoft recommends a mixture of these in development. Although it is clear that at this point Hungarian and All-caps are out of favor with most developers.

All-caps is the upper casing of every letter or using all capital letters. This holds on in the naming of constants or objects that are considered non moving.

Camel Casing has compound names using capital letters for the first letter and lower case for the rest with the exception of the very first letter. So if a variable is for a "file handle" it would be named "fileHandle". The memory device for this is to think the camel has the high point in the middle.

C-casing which is also called Underscore separation has the compound names joined with underscores; so "file handle" would be "file_handle".

Pascal Casing which takes it's name from the language Pascal where it became dominant has compound names using capital first letters for each part; as in "file handle"becomes "FileHandle".

Hungarian which became dominant in Visual C++ and Visual Basic and is in disfavor now is harder to formulate because there are many variations. It is my belief it has died of the weight of all the variations. Some key features of all variations is the prefixing of a single lowercase letter to indicate type. If the "file handle" was of type Handle it would be "hFile". Another common feature is to prefix this with "m_" to indicate class level scope.

The meaning of .vssscc .vspscc and .suo files.

The meaning of .vssscc .vspscc and .suo files.

Should .vssscc, .vspscc and .suo files be added to source Control?

The .vssscc and .vspscc should be added to source control and the .suo file should be excluded.

What is the easiest way to do this?

Use the "Add solution to source control" menu item.

What are these files?

The .vssscc file is referred to as the solution hint file. It has entries to help keep the solution in sync with source control.

The .vspscc file is referred to as the project hint file and it also helps to keep the project in sync with source control.

The .suo file stores user specific setting for Visual Studio. Since different team member can vary these settings it should not be checked in.

Fixing: Active Directory, Adding a Group to a Group

Problem description:
In some implementations of Active Directory you cannot Add a Group to a Group.

This is new functionality so to get this to work you will need to select the menu option "raise functionality".

C Sharp Interview Questions: Modifiers

Interview Quesions involving class and method modifiers.

1. What are the features of an abstract class?
Answer: It cannot be instantiated.It can contain abstrast methods and accessors.

2. When an non-abstract class derives from an abstract class with abstract methods or accessors what must it do?
Answer: It must provide implementations for all abstract methods and accessors.

3. What is an abstract method?
Answer: Implicitly it is a virtual method.Permitted only in abstract classes.It has no body.

4. Why are abstract methods not permitted in non-abstract classes?
Answer: Abstract methods have no implementation, which would be required in a concrete class.

5. When a field or local variable is marked const what does it change?
Answer: The value cannot change. It can only be initialized at declaration.

6. How is override used?
Answer: It is used to modify a method, property or indexer to change the implementation.

7. When a field is marked readonly what does it change?
Answer: The value can only be set in the constructor during initialization.

8. In terms of runtime and compile time, compare const and readonly.
Answer. const is compile time and readonly is runtime.

9. What is a sealed class?
Answer: The class cannot be derived by another class.

10. How does static change fields and methods?
Answer: They become global and belong to the type instead of the instance.

11. What is a virtual method?Answer: It is a method that implementation can be changed in a derived class by using the override keyword.

12. Why is modifiying a class with both abstract and sealed an error?
Answer: An abstract class cannot be instantiated

Visual Studio: Hot Keys: Windows

Most of the Hot Key chords for windows start with Ctrl W.
The ones that do not close windows or are data related.

Ctrl W A
Command Window

Ctrl W C
Class View

Ctrl W D
Code Definition Window

Ctrl W E
Error List

Ctrl W L
Server Explorer

Ctrl W O
Output

Ctrl W P
Properties

Ctrl W S
Solution Explorer

Ctrl W T
Task List

Ctrl W X
Toolbox


Ctrl Esc
Close Window

Ctrl Alt D
Data Sources

Ctrl F4
Close current tab

Ctrl Tab
IDE Navigator, first document (next document)

C Sharp Interview Questions: Operators

Questions involving Operators.

1. When the division operator "/" is used with two integers what is result?
Answer: An integer division with the remainder discarded ( 16 / 5 is 3).

2. What is the operator "%"?
Answer: It returns the remainder from the division.

3. What are the operators "" and ""? How do the differ?
Answer:
Operator "" is the bitwise-or operator.
It accepts boolean operands and integer operands.
The second parameter is always evaluated.
For integer operatands the individual bit places are or'ed separately.

Operator "" is the condition-or operator.
If the first operand is true the second parameter will not be evaluated.

4. What are the operators "&" and "&&"? How do the differ?
Answer:
Operator "&" is the bitwise-and operator.
It accepts boolean operands and integer operands.
The second parameter is always evaluated.
For integer operands the individual bit places are and'ed separately.

Operator "&&" is the condition-and operator.
If the first operand is false the second parameter will not be evaluated.

5. What are the operators '>>' and '<<'? Which mathematical operations are similiar? Answer: Operator '>>' is the right shift operator (right bit shift). It is similar to dividing by a power of 2.
Operator '<<' is the left shift operator (left bit shift). It is similar to multiplying by a power of 2.

6. What are the operators '?:' and '??' ?
Answer:
Operator '?:' is the conditional operator and is used in a statement in the form:
(conditional expression) ? (expression 1) : (expression 2)
If the (conditional expression) evaluates to true then the result of (expression 1) is returned.
If the (conditional expression) evaluates to false then the result of (expression 2) is returned.
Operator '??' returns the left operand if the left operand is not null otherwise it returns the right operand.

First look at Googles Protocol Buffer.

First look at Googles Protocol Buffer.

First the hype; Google wants you to think of Protocol Buffers as the New XML.
As such the list 5 reasons on the overview page for why Protocol Buffers have advantages over XML.
http://code.google.com/apis/protocolbuffers/docs/overview.html

1. Simpler
2. 3 to 10 times smaller
3. 20 to 100 times faster
4. less ambiguous
5. easier to program and generate data access classes

Two comments come to mind right off the bat.

Some of the performance gains come from poorly form xml design as such their are cases where the Protocol Buffer will be more than 10 time smaller and more than 100 times faster.
So it might condense things to say 3 times or more smaller and 20 times faster.
Lets look at the examples Google provides here is an xml snippet


John Doe
jdoe@example.com


And here is the thing which is NOT the protocol buffer

# Textual representation of a protocol buffer.
# This is *not* the binary format used on the wire.
person {
name: "John Doe"
email: "jdoe@example.com"
}

The 'Not' is important here because the protocol buffer is not stored in a human readable or text format.
It is stored as binary, which means human readability is gone.
No matter, but looking at the example it is hard to see how if I use a absurdly long name, how the XML would be three times larger than the Protocol Buffer.
In fact as I push it out to large lengths the two formats should have a ratio of sizes of about 1 to 1.

The faster is easy to see.
We will not be opening and closing a bunch of tags and the tags themselves have opening closing brackets that aid human comprehension but become dead weight repetitive.
But in the counter example used for size it is hard to see how the same example would not show a speed ratio between the formats of 2 to 1.

Now on the upside.
Clearly it is less ambiguous. If you have tried to make XML live up to its hype you know the ambiguous pitfalls.
The "easier to program and generate data access classes" is function of Protocol Buffers being more constrained in what they will support and what is legal.
History relives itself here, XML was the same "simplify to gain power" condensing of HTML.
Likewise HTML condensed SGML.

There is another fundamental divergence from XML. You could use XML without documenting the schema.
This was in classic software fashion the greatest strength in rapidly spreading XML because there were no rules.
And the greatest weakness in that there where no rules so we never were 100% sure what documents meant or if they were well formed or complete.
This is diffent in that Protocol Buffers are defined in "Protocol Buffer Message Definitions" stored in a ".proto" file.
These are similiar to XML's DTD or Schemas.
The difference is they are now required.
Again there is the history flashback, HTML did not require closing tags, XML did and that made all the difference.

Obsolete's Key Role In Agile Software Development

There is one attribute that has a unique and powerful roll; Obsolete.

Here are four examples applications to the same function 'Funky'

1:
[Obsolete()]
void Funky(){...}

2:
[Obsolete("Use Freaky instead")]
void Funky(){...}

3:
[Obsolete("Use Freaky instead", false)]
void Funky(){...}

4:
[Obsolete("Use Freaky instead", true)]
void Funky(){...}

Starting with 1 you can use this attribute without any of the parameters. In this default mode it will generate a warning indicating the method is obsolete. Following the rule of "Making the Right thing Easy and the Wrong thing Hard" this should be avoided in favor of 2; Use the message string to explain what should be done instead.

Example 3 is equivalent to 2, the second parameter determines if the Obsolete attribute results in a warning (false, the default) or an error (true). It is rare that you will actually have this set to true (4) and checked in to source control, since that would break the build. But it does happen and it is a more elegant way of making "The Wrong thing Hard" than commenting out the obsolete code.

How you will use 4 is to explore the level of effort involved in changing code. In a typical "Drain A Swamp" effort; the code might not even compile from source control without error. After considerable effort you will get the errors out but be left with numerous warnings. This morass of warnings will hide the ones generated by Obsolete. So working with generate error set to true will provide a count of what is left and a road map of what to fix.

In Green Field efforts Obsolete provides a effective means of communication of intent between teams working on separate modules. It raises the flag that one team wants to change something but does not force another team to change immediately. Perhaps the second team needs to transform and obsolete some code as a result. On balance it allows for teams of programmers to behave in an agile manner.

But perhaps the best benefit of Obsolete is the knowledge that it is there and provides a way for a programmer to take back his mistakes. What is not stressed enough about Agile methodologies is that it is a safe way for programmers to make mistakes. This frees them to discover things that can never be known beforehand in a Command and Control Central Planning mode of development. By fearless experimentation and ruthless obsoleting programmers will flow past problems, discovering the easy way much like water finds the downward path to the sea.

Visual Studio: Hot Keys: Solutions Projects Files

Ctrl Shift N
New project

Ctrl Shift O
Displays the Open Project dialog

Shift Alt C
Add New Item, with class as default

Shift Alt A
Add Existing Item

Ctrl Shift A
Add New Item, with file as default

Ctrl Alt Down Arrow
Displays list of all open documents

Ctrl O
Open File Dialog

Visual Studio: Hot Keys: Refactoring

Note all of the Refactoring Hot Key Chords start with Ctrl R.

Ctrl + R E
Encapsulate a Field, creates a property from a field

Ctrl + R I
Extract an Interface, create a new interface from an existing class, interface or struct

Ctrl + R M
Extract Method, create method from code selection

Ctrl + R P
Promote to Parameter, promote a local variable to a parameter

Ctrl + R V
Remove Parameters

Ctrl + R R
Rename, allows renaming of identifier

Ctrl + R O
Change Order of Parameters

C Sharp Interview Questions: Access Modifiers

Questions involving C# Access Modifier keywords.

1. Describe how the keyword "internal" affects access.
Answer: can only be accessed from the same assembly

2. Describe how the keyword "private" affects access.
Answer: can only be accessed from same class or structure

3. Describe how the keyword "protected" affects access.
Answer: can only be accessed from the class where it is declared or a derived class

4. Describe how the keyword "public" affects access.
Answer: No Restriction

5. Can multiple access modifiers be used on a member or type.
Answer: Only the combination "protected internal" is allowed

6. What is the default accessibility of an enum?
Answer: public

7. What is the default accessibility of an interface?
Answer: public

8. What is the default accessibility of a class ?
Answer: private

9. What is the default accessibility of an struct?
Answer: private

Index Of C# Interview Questions

Index Of C# Interview Questions

Actors

Agarwal Corollary

Agarwal's Law

AP Calculus

ASPNET account

backupfile

backupset

Bright Shiny Object

Bug Focus

Build

C#

Calculus

Code Pattern

Cognitive Load

Compact Net Framework

Coroutine

Daisy Chain Bug

Desktop Virtualization

DEV

Dot Net Framework

Dot Net Singularity

DotNet Singularity

Enterprise Agreement

enum

Even More Law

EventHandler

Exception

Exception Handling

Feature Focus

FileSystemWatcher

Firefox

Five Nines

Full Package Retail

Generator

GPS

helpctr.exe

hex literal

Hyper VTM

IEnumerable

IIS

Index

installer

INT

integer literal

Intellisense

Internet Explorer

Interviewing

Join

Linux

Micro Dot Net Framework

Microsoft Application Virtualization

Microsoft Team System

Microsoft Virtual PC

Mono

Moonlight

Moore's Law

msdb

msinfo.exe

msinfo.htm

MsTest

MultiBrain

MultiCore

multiplatform

MultiThread

Net Framework

NETWORK SERVICE

NUnit

Open Business

Open Value

Open Value Subscription

Parse

Permutation

Poisoned Candy

Prod

Production

QA

Refactor

Regex

Regression Bug

Requirements

Select License Agreement

Separation of Concerns

Serial Port

Server Virtualization

ServiceController

ServiceProcess

Silverlight

Snippets

Software Development

Software Development Practices

Source Control

Sprint

Sprint Aircard

SQL Server

Subroutine

System

System Info

System.Exception

Team Server

Team System Build

TfsBuild

Thread

ThreadStart

Three Nines

TryParse

UAT

uint

Unix

Use Case

User Acceptance Testing

VB.net

Version Control

Virtualization

Visual Studio

VJ#

Web Service

Win32

Win64

Windows Server

Windows Terminal Services

Windows XP

yield

Visual Studio: Hot Keys: IntelliSense

IntelliSense Hot Keys

Ctrl + space or
Ctrl + K W
Complete word using the current selection in the list

Ctrl + J or
Ctrl + K L
Pull up the intellisense selection list

Ctrl + K I
Show the declaration of selected identifier in a Quick Info tool tip

Ctrl + Shift Space or
Ctrl + K P
Display for the specified method the name and parameters required

When Intellisense Selection List is displayed:
Ctrl causes the list to be rendered transparent

Mono Dot Net Framework

Novell picked up leadership of the Mono project from Ximian. Since the common language runtime and dot net languages like C# have been submitted (and approved ) as ECMA standards, it should be possible to port the Dot Net Framework, Common Language Runtime and Dot Net languages to other platforms.

This is the goal of the Mono project. It currently can be run on Linux, some Unix, BSD, Mac OS X, Solaris and even Windows OSes. To do this the JIT (just in time compiler) needs to support many chipsets the x86, SPARC, S390, 64 bit x86 and others.