Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Http Modules :: how to bypass the standard ASP.NET pipeline behaviourHttp Modules :: how to bypass the standard ASP.NET pipeline behaviour
Previous
 
Next
New Post
5/2/2007 4:15 AM
 

So, in a nutshell what all this is telling me so far, is, that there is no way to bypass the pipeline's Http Modules (which seems to be a general ASP.NET issue rather than something specific to DNN, right ?). So the discussion is left with the question about what the Http Modules shall be:
 
Of course there are many good reasons why the Http Modules are the way they are - as long as you have the DNN application scenario's in mind, DNN originally has been architected for - Portals and Modules.

But there are also other scenarios that do not fit into this pattern:  For instance take the DNN's own KeepAlive.aspx which, although it just returns the system time, still goes through all the HttpModules' overhead !

In my case, all my client application requests will be channeld through a single, portal, module and user independent Gateway, that again might or might not route all the traffic forward to the DNN business objects in charge.
In this setup, some of the requests will just "poll" the Gateway's own status (similar to KeepAlive.aspx) - and therefore has absolutely nothing to do with DNN and does not need ANY of the HttpModule's functionality.

Anyway, DNN is a great system and maybe my concerns have just risen, because I am trying to extend DNN into a direction it was never ment to be. DNN's whole architecture is based on Portals and Modules and this is a great thing for most of us.
On the other hand, I am currently not clear, about the concept for extending DNN on APPLICATION level (in my case, having a different entry-point than default.aspx).

So my final conlusion here so far is: The current Http Modules' view is "Portal/Module" only and currently do not allow a more generic host-level approach that runs beside rather than "on top" of the current Portal/Module paradigm.
right ?

hmm - seems that my concerns have become some sort of academic and maybe, now that I have got the confirmation that DNN ist what it is, it is time to go back to code again.

Thank you all for your help - was very insightfull

kind regards
Rene

P.S.
to keep the discussion somehow focused on the PIPELINE:
I absolutely agree, that the pipline issues is NOT the major performance threat - but the issue I want to discuss, is not performance in GENERAL, but the PIPELINE's role and performance impact for the scenario's mentioned above.

 
New Post
5/2/2007 8:04 AM
 

Rene,

  I think that this is a good type of discussion to have every once in a while since it keeps us focused on making the right architectural decisions.   Is a service needed for every request to the system?  Or is it only applicable to actual web pages?  What is the performance impact of using yet another module?  I think in many cases we have made the right decisions, but we still have a couple that probably should be changed. 

One thing to keep in mind is not that we only support the portal/module paradigm, but more importantly that much of our API has certain base requirements.  We absolutely must know who every request is coming from - be it an anonymous request or a validated user.  We also need to know which portal a request is intended for - since again this has security implications.  We also need to make sure that the application responds appropriately in failure situations.

After doing some further research, it appears however that there is a solution to your specific issue:  create a web.config in your module directory (you might want it to be a sub-directory for your module so you have control over the pages affected).  This web.config would only have a section for the HTTPModules and would just add those modules that are critical for base functions:

<configuration>
    <
system.web>
        <
httpModules>
            <
clear/>
            <
add name="UrlRewrite" type="DotNetNuke.HttpModules.UrlRewriteModule, DotNetNuke.HttpModules.UrlRewrite" />
            <
add name="DNNMembership" type="DotNetNuke.HttpModules.DNNMembershipModule, DotNetNuke.HttpModules.DNNMembership" />
        </
httpModules>
    </
system.web>
</
configuration>

The key here is that I first use the "clear" element which removes all of the httpModules from the web.config heirarchy and then I can selectively add in those modules that I really need.  This will mean that for any resource request into the folder where this web.config resides, only these modules will be processed.

NOTE: Keep in mind that this also clears the modules that ASP.Net includes in the root system web.config.  You should look at the defaults and see if any of those should be added back in to suit your needs.  It is possible that one or more of those will be needed by UrlRewrite or DNNMembership in order for the security model to work correctly.


Joe Brinkman
DNN Corp.
 
New Post
5/2/2007 10:27 AM
 

Joe

working with sub-folder specific web.config files might most probably do the trick. Maybe it is not the most elegant solution but definitively one that will bring us a step forward.

no question left for me

thanks a lot for your help

 
Previous
 
Next
HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Http Modules :: how to bypass the standard ASP.NET pipeline behaviourHttp Modules :: how to bypass the standard ASP.NET pipeline behaviour


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out