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
