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
