In a web environment, you don't want to expose your internal components to be executed via URL. The top-level extension lets you define your "API" to end-users as it were.
It's less necessary for an environment where Mason is just the view, since you've already got a controller in between Mason and the end-user. Jon On Mar 3, 2011, at 1:15 PM, Matthias Dietrich wrote: > Just a question: what is the reason for having two different file extensions > for top-level and internal components? > > -- > > Sent from my iPhone so expect spelling errors and stuff. > > rainboxx Matthias Dietrich > Freelance Software Engineer > > rainboxx > Königsallee 43 > 71638 Ludwigsburg > +4915150607864 > > Vist: http://www.rainboxx.de > > Am 03.03.2011 um 21:43 schrieb Kurt Hansen <k...@charityweb.net>: > >> On 3/3/11 2:34 PM, Jonathan Swartz wrote: >>>> On 3/3/2011 6:09 AM, Jonathan Swartz wrote: >>>>> I want Mason 2 to have default file extensions that it facilitates and >>>>> enforces (though they can be changed via parameters). Here's what I'm >>>>> thinking of going with: >>>>> >>>>> .mc - top-level component >>>>> >>>>> A top-level component can serve as the page component in a request. >>>>> >>>>> .mi - internal component >>>>> >>>>> An internal component can only be accessed from other components. >>>>> >>>>> .mp - pure-perl component >>>>> >>>>> A pure-perl component contains only code; it is parsed as if its entire >>>>> content >>>>> was within a<%class> block. You do not need to (and are not allowed >>>>> to) include >>>>> Mason tags in this component, and it will not produce any output if >>>>> called. >>>> >>>> Make sure it can be EASILY overridden. From a security standpoint, it is >>>> not a good idea to reveal the technology behind your systems. As an >>>> example, PCI compliance scanning will fail if your web server reveals more >>>> than just its name (Apache). >>>> >>>> All the sites I do with Mason use .html as an extension. While they are >>>> obviously dynamic and not just plain HTML, it can be difficult to discern >>>> if they are written in Mason, PHP, Cold Fusion, etc. When an attacker >>>> sees a URL that ends with .aspx, he knows he can throw his microsoft >>>> attack tools at it and not bother with the PHP ones (unless the admin is >>>> clever and the site is really PHP and not ASP). Keeping attackers >>>> guessing makes their job harder and your site safer. >>> To clarify, these are not URL extensions, they are file extensions. That >>> is, by default, the URL >>> >>> /foo/bar >>> >>> would be handled by one of these components >>> >>> /foo/bar.mc >>> /foo/bar.mp >>> >>> or a dhandler, etc. There's no way to know from the URL "/foo/bar" that you >>> are using Mason versus something else. >>> >>> If you want URLs like /foo.html, you could either create files like >>> /foo.html.mc, or you could set autoextend_request_path to false and create >>> files like foo.html. >>> >>> So I don't see any security implications with Mason having a standard set >>> of file extensions, but please correct me if I'm wrong. >> I agree, Jon. I don't see any security implications. Also -- PCI doesn't >> fail because you reveal more about Apache. It fails if the version of >> Apache you are announcing is one that has a known weakness. In fact, it >> might be better to reveal what you have to your scanner tool so they >> alert you as soon as possible about a vulnerability. But, that's a bit >> beside the point... >> >> I vote yes on the .mc/.mi/.mp. I already use the .mc for Mason >> components so I was glad to see the switch from .m (which would have >> been a pain) to .mc. Of course, it would be good to make it configurable >> on a site basis. >> >> Another benefit of standard component extensiions -- maybe some standard >> editors (Eclipse? Dreamweaver? Others?) will have plugins for Mason >> components built. >> >> Take care, >> >> Kurt Hansen >> >> -- >> _____________________________________________________________ >> >> What's the reason we're alive... >> Bound to stumble and fall >> but my strength comes not from man at all. >> --Matisyahu from the song "Miracle" >> ______________________________________________________________ >> >> Kurt Hansen >> Founder and CEO >> CharityWeb >> Rockville, MD >> Toll-Free: (866) 438-6657 x101 >> Direct: (301) 984-0026 >> k...@charityweb.net >> http://www.CharityWeb.net >> >> >> ------------------------------------------------------------------------------ >> What You Don't Know About Data Connectivity CAN Hurt You >> This paper provides an overview of data connectivity, details >> its effect on application quality, and explores various alternative >> solutions. http://p.sf.net/sfu/progress-d2d >> _______________________________________________ >> Mason-users mailing list >> Mason-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mason-users > > ------------------------------------------------------------------------------ > What You Don't Know About Data Connectivity CAN Hurt You > This paper provides an overview of data connectivity, details > its effect on application quality, and explores various alternative > solutions. http://p.sf.net/sfu/progress-d2d > _______________________________________________ > Mason-users mailing list > Mason-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mason-users ------------------------------------------------------------------------------ What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
