Thursday, February 17, 2011

Forums are evil?

Don't understand me wrong - I'm not against forums, blogs and other community related activities. I just want to consider one usual situation.
Junior developer faced with a problem. And of course as usual this problem has appeared out of the blue where none could expect and caused by not knowing basics of used technology. What does junior do? Start learning the elements - no! Start trying to dig the technology - no! Today everyone knows the magic word "google", "bing" (etc - insert your favourite search engine). Junior quickly hammer the question into the search box and voilà  - they could get answer on some forums!

And now let's look at forums' contingent and even assume that there are some expers in necessary sophere.

An expert open forum, sees junior's question and moaning "ohh, lamers have completely cowed me" and skips it.
Another junior opens forum, sees the complex (from their point of view) querstion and starts reasoning.

Results usually are regrettable. Answer could be obtained, but there is no guarantee that it would be right. And I repeat - it's not always! And yes, sometimes you can get an answer from the man who thinks in right direction. And sometimes questions are not lame. But all my many years experience of juniors upbringing cries: "Learn the basics!!!"

P.S. There are some communities like experts-exchange, in which it's much easier to find right answers and where much more experts. I was registered there and obtained the status of expert, but it's a pity, to support this status you need time but not all seniors have it :(

So, forums are not evil if you are ready and if it's a right forum :)

RUS: http://asliborsky-ru.blogspot.com/2011/02/blog-post.html

Thursday, December 17, 2009

All Validation Techniques in ASP.NET MVC

Authors and editors: Sergey Khalipsky, Aleksandr Sliborsky
In the first article (Validation Techniques Comparison) we just considered the most useful and the best techniques that could be used for validation implementation in ASP.NET MVC.
We don’t want to deprive you of a pleasure of doing all this by yourself, so we will just give you a direction and some samples of implementation and let you dig deeper .
So, today’s agenda is:
  1. Manual validation in Model Binder and Controllers (client validation type 1 and server validation type 1)
  2. DataAnnotations (client validation type 2, server validation type 2);
  3. Custom Validation engine implementation (client validation type 1, server validation type 2);
  4. Spring Validation Framework usage on a server, manual validation on a client (client validation type 1, server validation type 3)
  5. Spring Validation Framework usage on a server, DataAnnotations + manual validation on a client (it’s a mix from several points from previous review);
  6. xVal Validation Framework
Let’s start fingerscrossed

Tuesday, December 15, 2009

Advanced validation techniques in ASP.NET MVC


Authors and editors: Khalipsky Sergey, Sliborsky Aleksandr

Introduction

When you start development using new technology or framework several questions are arisen: how does it support work with RDBS, how to implement UI better etc.
And, of course, – Validation.
There are several solutions on how to implement validation in the projects based on ASP.NET MVC. When our company first time faced with the ability to implement a solution based on this technology we made an analysis of all viable possibilities. This article and some upcoming articles are the results of those investigations. In this, first article we will consider more theoretical questions and just consider why we have chosen this or that approach in validation. In the next article we will consider implementation of different approaches.

Monday, December 14, 2009

SharePoint Security. Part 1. Introduction


When our company involved into SharePoint development as Security consultants or when we asked to improve legacy system we very often shocked by the level of security of that systems and by the implementation efforts applied to it. Sometimes it seems that all we are working in trust environment where everyone is a saint and there is no thefts, corruptions and other sins.
We prepared the series of articles which should help in security implementation and design in SharePoint portals. This is only the first one from this series.

Monday, December 7, 2009

ASP.NET MVC WebForms vs Spark View Engines. Part 2. Markup

In my previous article (ASP.NET MVC WebForms vs Spark View Engine. Part 1) I had started to describe the differences between standard ASP.NET MVC View Engine and spark. In this short article I will just show the differences between implementation of 3 equal pages.
So, less words, more code…

Friday, December 4, 2009

ASP.NET WebForms vs Spark View Engine. Part 1


Preamble

There is no "the best", "one fits all" engine, framework or something else. I didn't try to choose the best, I just tried to investigate the possibilities to have them in mind for line of the upcoming projects and to have a possibility to choose between them depending on the requirements.
Also, I’m not a guru in both engines, I had just made a surface comparison and appreciate any comments, fixes and additions!

Monday, September 22, 2008

What's wrong with Spring.Net Interceptors?

When I began using of Spring.Net interceptors part of my code stopped working! For example such code:


public class POBlo
{
    private IDataProvider _dataProvider = null;
    // Yes, I know about auto property :)
    protected virtual IDataProvider DataProvider
    {
        get { return _dataProvider; }
        set { _dataProvider = value; }
    }
 
    public virtual void Save (Entity entity)
    {
        // Here we have NullReferenceException :(
        DataProvider.Save (entity);
    }
}

Before I added interceptor all were OK. I could save entity and no exception was occurred.

After some investigation I've found the problem: intercepted target object has right value of this property but proxy object does not expose it!
Finally I opened Spring.Net sources and found the Spring.Proxy.AbstractProxyTypeBuilder's InheritType method the proxies my class:



protected virtual void InheritType(TypeBuilder typeBuilder,
            IProxyMethodBuilder proxyMethodBuilder, Type type, bool declaredMembersOnly)
{
    IDictionary methodMap = new Hashtable();
    IList finalMethods = new ArrayList();
 
    BindingFlags bindingFlags = BindingFlags.Public  BindingFlags.Instance;
    if (declaredMembersOnly)
    {
        bindingFlags = BindingFlags.DeclaredOnly;
    }
 
    // override virtual methods
    MethodInfo[] methods = type.GetMethods(bindingFlags);
    foreach (MethodInfo method in methods)
    {
        if (method.IsVirtual && !method.IsFinal)
        {
            MethodBuilder methodBuilder = proxyMethodBuilder.BuildProxyMethod(method, null);
            ApplyMethodAttributes(methodBuilder, method);
            methodMap[method.Name] = methodBuilder;
        }
    }
    // override virtual properties
    foreach (PropertyInfo property in type.GetProperties(bindingFlags))
    {
        ImplementProperty(typeBuilder, type, property, methodMap);
    }
    // override virtual events
    foreach (EventInfo evt in type.GetEvents(bindingFlags))
    {
        ImplementEvent(typeBuilder, type, evt, methodMap);
    }
}

As you can see, Spring's default implementation creates proxy just for publicly published interfaces of the class. So first obvious solution is to mark all properties "public" instead of "protected". But this is unacceptable because of different reasons: huge reworking and (what is more important) encapsulation violation.

So I've decided to just reimplement this solution. This is quite easy with DI and Spring.Net. Simply follow the steps:
1. Create custom ProxyTypeBuilder.
2. Create custom ProxyFactory
3. Register ProxyFactory in configs.




Create custom ProxyTypeBuilder

Create custom proxy type builder where we define necessary binding flags.



 
using System;
using System.Collections;
using System.Reflection;
using System.Reflection.Emit;
using Spring.Aop;
using Spring.Aop.Framework;
using Spring.Aop.Framework.DynamicProxy;
using Spring.Proxy;

namespace Qulix.Spring.Aop
{
    /// 
    /// Implements proxy type builder that uses inheritance and exposes not only public methods
    /// 
    [CLSCompliant(false)]
    public class CustomInheritanceProxyTypeBuilder : DecoratorAopProxyTypeBuilder
    {
        #region IProxyTypeBuilder Members
        [CLSCompliant(false)]
        protected override void InheritType(TypeBuilder typeBuilder,
                                            IProxyMethodBuilder proxyMethodBuilder, Type type, bool declaredMembersOnly)
        {
            IDictionary methodMap = new Hashtable();
            BindingFlags bindingFlags = BindingFlags.NonPublic  BindingFlags.Public  BindingFlags.Instance;
            if (declaredMembersOnly)
            {
                bindingFlags = BindingFlags.DeclaredOnly;
            }
            // override virtual methods
            MethodInfo[] methods = type.GetMethods(bindingFlags);
            foreach (MethodInfo method in methods)
            {
                if (method.IsVirtual && !method.IsFinal)
                {
                    MethodBuilder methodBuilder = proxyMethodBuilder.BuildProxyMethod(method, null);
                    ApplyMethodAttributes(methodBuilder, method);
                    methodMap[method.Name] = methodBuilder;
                }
            }
            // override virtual properties
            foreach (PropertyInfo property in type.GetProperties(bindingFlags))
            {
                ImplementProperty(typeBuilder, type, property, methodMap);
            }
            // override virtual events
            foreach (EventInfo evt in type.GetEvents(bindingFlags))
            {
                ImplementEvent(typeBuilder, type, evt, methodMap);
            }
        }
        #endregion
    }
}


As you can see I've added extra BindingFlags. This will allow to find and proxy not only public properties and methods.


Create custom proxy factory


Just inherit from one of the implemented Proxy factories and reimplement CreateAopProxy method:



[Serializable]
[CLSCompliant(false)]
public class InheritanceAopProxyFactory : DefaultAopProxyFactory
{
    [CLSCompliant(false)]
    public override IAopProxy CreateAopProxy(AdvisedSupport advisedSupport)
    {
        if (advisedSupport == null)
        {
            throw new AopConfigException("Cannot create IAopProxy with null ProxyConfig");
        }
        if (advisedSupport.Advisors.Length == 0 && advisedSupport.TargetSource == EmptyTargetSource.Empty)
        {
            throw new AopConfigException("Cannot create IAopProxy with no advisors and no target source");
        }
 
        IProxyTypeBuilder typeBuilder = new CustomInheritanceProxyTypeBuilder(advisedSupport);
        Type aopProxy = BuildProxyType(typeBuilder);
        ConstructorInfo constructor = aopProxy.GetConstructor(new Type[] { typeof(IAdvised) });
        return (IAopProxy)constructor.Invoke(new object[] { advisedSupport });
    }
}

Here we just replace creation of ProxyTypeBuilder with our own CustomInheritanceProxyTypeBuilder. Of course, you can parametrize you ProxyFaxtory to accept type of the ProxyTypeBuilder. I do not implement this functionality for simplicity.


Register ProxyFactory in cofig


As last step we need to define what IAopProxyFactory implementation will be used. For this purpose write in the configuration file the following:


 
<object id="IAopProxyFactory" type="Qulix.Spring.Aop.InheritanceAopProxyFactory, Qulix.Spring" />
 

That's it. Now we just need to define the reference to our ProxyFactory implementation. For example:



<object id="POBloProxier" type="Spring.Aop.Framework.AutoProxy.ObjectNameAutoProxyCreator, Spring.Aop">
    <property name="AopProxyFactory" ref="IAopProxyFactory" />
...

I hope this will help you. And you will help me to find easier and more clearer solution.

kick it on DotNetKicks.com
Share this Post:

Facebook
Digg DelIcioUs

Wednesday, September 17, 2008

Security implementation tips

How do you implement security in your ASP.NET application?

I propose to use AOP and interceptors. Short sample.

You have business logic methods like:

public List<Action> GetActions();
public void ExecuteAction(Action action, object data);


And you don't care about security there. You just do your job: create list of all supported actions and return it in GetActions and execute any supported actions in ExecuteAction. Smart, clear and straightforward.

But where is security? In interceptors.

You create interceptor that wraps these two methods. These interceptor knows about allowed actions and has access to such list of actions.

On every execute of GetActions it intersects List of returned actions with list of allowed actions and returns the result of intersection.

On every execute of ExecuteAction it checks whether action is allowed or not.

So you:
1. Have separate security mechanism that works independently.
2. Do not care about security during business logic development.
3. Can split these tasks and divide them between different people.
4. Can use other tips mentioned below :)


And few more tips with security:

1. Always try to separate logic from security as much as possible. This allows you to separate concerns, divide work and allows developers to concentrate on their narrow task.

2. Add possibility to switch off the security. Sometimes it's necessary to test if error occurred because of business logic failure or security failure. It's hard to do if there is no possibility to switch off security. It's not a hard task but it could save time during testing and stabilization.

3. Remove possibility to switch off security from production version. There is a risk that somebody could change your configuration parameter directly or indirectly and in such way perform leverage privileges attack. To avoid this, remove security switch off from production code. But do not delete code! Just use the following:


private bool IsSecurityEnabled
{
    get
    {
#if DEBUG
        return Configuration.IsSecurityEnabled;
#else
        return true;
#endif
    }
}

4. Avoid possibility to delete last administrator. To prevent system from being "unadministrable" add code that will check all delete operation on subject of is there any administrators in the system or last one is deleted. Or select one "Super Administrator" that could be removed from the system.

5. Make security as fast as possible. Create User permissions tickets to save all user allowed actions, cache actions etc. Security should be quick because may be used often.

6. Check security on business logic level. Do not rely on GUI. On UI level you should concentrate on UI as much as possible and do not make security checks where allowed. Or GUI could be even compromised, or UI developer could forget to exclude operation from UI. Moreover, later customer could ask you to write another client based on current application logic level.


To be continued... :)

kick it on DotNetKicks.com




Share this Post:

Facebook


Digg


DelIcioUs