Posted
7 months
ago
by
Peter J. Farrell
pe...@mach-ii.com
Posted
7 months
ago
by
Brian Pickens
brian.m...@gmail.com
Posted
7 months
ago
by
Peter J. Farrell
pe...@mach-ii.com
Posted
7 months
ago
by
Brian Pickens
brian.m...@gmail.com
Posted
7 months
ago
by
Brian Pickens
brian.m...@gmail.com
Posted
7 months
ago
by
peterfarrell
As a side note, the environment property and supported stuff incurred a rather large discussion on the team. It was things like this ultimately convinced people and now I wouldn't want to go back (the big thing was one the resolveValueByEnvironment
... [More]
method available in the BaseComponent -- makes life so easy for my custom plugins / filters / listeners).
Yes, yes, Brian, do the wiki entry! [Less]
Posted
7 months
ago
by
bklaas@…
You beat me to the punch on suggesting the use of environment variables, Peter! =D
The lack of https on most local development machines is a great reason to use the environment configuration options in 1.8. Yet another item to go in the wiki entry I need to commit to writing.
Posted
7 months
ago
by
peterfarrell
@Jonah,
Agreed on the part that secured URLS may have a different domain (sub-domain -- they do some of my applications -- being cheap and not wanting to pay for wildcard certificate) and that in development / staging / testing environments
... [More]
these URL bases may be different. Easily solved by an additional property as you suggested and the use of the EnvironmentProperty?:
<property name="Environment" type="MachII.properties.EnvironmentProperty">
<parameters>
<parameter name="defaultEnvironmentName" value="production"/>
<parameter name="development">
<struct>
<key name="environmentGroup" value="development"/>
<key name="servers" value="m2website"/>
<key name="properties">
<struct>
<key name="urlBase"value="http://www.example.net" />
<key name="urlBase"value="http://www.example.net" />
</struct>
</key>
</struct>
</parameter>
<parameter name="production">
<struct>
<key name="environmentGroup" value="production"/>
<key name="servers" value="www.mach-ii.com,mach-ii.com"/>
<key name="properties">
<struct>
<key name="urlBase"value="http://www.example.net" />
<key name="urlBase"value="https://secure.example.net" />
</struct>
</key>
</struct>
</parameter>
</parameters>
</property>
That builds on top of are already great environment stuff for 1.8 and gives you the most flexibility. [Less]
Posted
7 months
ago
by
.jonah
This is turning into quite a thread!
I'm excited by what @peterfarrell said in #comment:11 about the secure=true attribute affecting buildURL() as well.
I have two thoughts based on my experience:
1. I don't have SSL in my
... [More]
dev environment, so both securedUrlBase and urlBase are HTTP.
2. Like I mentioned in #comment:4, sometimes secure URLs have a separate third level domain hxxps://secure. vs hxxp://www.. so simply prepending HTTP or HTTPS wouldn't work.
I propose that both of these situations could be resolved by buildURL() using two properties in production:
<property name="urlBase" value="hxxp://www.store2.net" />
<property name="securedUrlBase" value="hxxps://secure.store2.net" />
And these two in development:
<property name="urlBase" value="hxxp://www.store2.net" />
<property name="securedUrlBase" value="hxxp://www.store2.net" /> [Less]
Posted
7 months
ago
by
peterfarrell
Well, I think having a concrete example will help us here. Let's say their is an email a champaign and it has a URL like this:
http://www.example.com/index.cfm?event=doABC&userId=123987
The event-handler for doABC would look
... [More]
like this:
<event-handler event="doABC" access="public" secure="true">
... commands here ...
</event-handler>
So the user clicks the link (which is just normal HTTP) and Mach-II receives the request. Mach-II goes "oh, this needs to be secure - lemme handle that for you" and redirect to this URL:
https://www.example.com/index.cfm?event=doABC&userId=123987
So the framework will negotiate the request to the correct protocol as needed based on the meta-data it has in event-handler. The vice-versa would be true if a HTTPS request comes in for an event that is not required to be secure. BuildUrl would generate the appropriate HTTP/HTTPS url based on if the event-handler is marked as secure (by default the secure="false" would be the default).
So I think that handles your edge case of an user having a non-secure URL that really needs to be HTTPS as the framework handles the enforcement. As for form POSTs that need to be sure, the form action needs to POST to a secure URL (or have the form page be HTTPS in the first place so the protocol doesn't need switching). This is no different than in a non-Mach-II application -- this needs the developer's attention to detail because anybody can take an HTTPS url and switch it to HTTP -- we can't stop people from messing with that stuff. It comes down to the framework enforcement -- something we can off load to the framework easily. [Less]
