Thursday, November 27, 2014

Integrating servicestack 3 into DNN - Part 1 - Introduction

Introduction

In this series of blogs, I will try to share my thoughts of using ServiceStack 3 in DotNetNuke 6, difficulties, limitations and how I finally solve each problem step by step.

Part 1 - Introduction

Background

I started looking at ServiceStack 3 years back when I was working with one of the client who provided ServiceStack services and asked me to use them as back end instead of storing data in DotNetNuke database.

At the end of project, I learned a lot about servicestack.client and associated facilities and then I invested some time using servicestack to deliver rest base services. Now a days ServiceStack and asp.net web API both are obvious options if you are planning to start any asp.net web services along with WCF. It depends on your experience, your team's experience an vision a lot.

After learning ServiceStack, I utilized it in couple of asp.net based projects which are either conversion of cold fusion to .net services or interoperable database independent service development with .net and I was very happy with the way I achieved best results because of ServiceStack

So, some time back, when I started architect a new web platform for one of my recent client, who was using DotNetNuke and wanted their platform to support APIs so that they can be used with navite mobile apps, I decided to use ServiceStack again in this scenario as well!

Try ServiceStack 3 Hello world!

  1. From Nuget Package Manager Console:
    install-package servicestack -version 3
  2. Since I wanted the base url of the servicestack to start from /api/ instead of / I did some web.config modifications:
    1. In handlers section added following line:
       <add path="api*" type="ServiceStack.WebHost.Endpoints.ServiceStackHttpHandlerFactory, ServiceStack" verb="*" />
    2. in modules section added following line:
       <add name="ServiceStack.Factory" path="api*" verb="*" type="ServiceStack.WebHost.Endpoints.ServiceStackHttpHandlerFactory, ServiceStack" resourceType="Unspecified" requireAccess="Script" allowPathInfo="true" preCondition="integratedMode" /> 
    3. If you have webdev enabled, do following to support PUT, DELETE verbers ONLY if these verbs are not working in handlers section:
      <remove name="WebDAV" />
Now, servicestack hosting on web requires writing code in global.asax Application_Start event and I was stuck there! I found more than one solution on internet to achieve this, but I decided to modify the code to add another line to initialize servicestack by writing: new AppHost().Init()

I know change dotnetnuke core dll is not good practice. Suggestions are welcome to fix this in the best possible way!

In the next part we will start coding a real api!

Saturday, July 26, 2014

Do you really need role base pages in dotnetnuke?

Introduction & Background

I have experience working on an existing dnn site that has lots of custom features and I join the team to contribute as developer, lead or code reviewer. Many times during last 8 years of such experience, I found lots of people are creating role base pages in dotnetnuke and implement some custom login in either login module or somewhere else that can check the role and redirect.

Is this really required?

Example Scenario

Lets say you are working on a hospital portal in dotnetnuke and want to prepare a dashboard for care taker, admin, manager, and bunch of other roles. 

If you create different pages and drop a single module for role wise dashboard, and use some custom logic to redirect user after login to that page, that is something that needs a second though.

Dotnetnuke security inherited from portal > Tab > Module. Inheriting up to module level is recommended for most of the cases.

I would create a page(tab) and drop all the modules that I prepared for role wise dashboards. I would do multiple modules to make things separate and clean but drop all modules to the same page. In module settings of each module, uncheck the inherit permission button and check the role which is expected to see this module. 

Now, without having too much of coding/customization and tricks, each role can easily access data that is expected to their roles. Easy!

What do you think?



Popular Posts