SSL and Ionics Redirect - Execution Order?

Here is the situation. I have a web site where two folders (In a virtual directory) need to be run under SSL. I have figured out how to use a RedirectRule to push people to the "HTTPS" or SSL location of these pages.

But here is the behavior I'm seeing, IIS 6.0

1) SSL certificate is installed on IIS Server, by using the Ionics ISAPI filter I can push people to the "Secure" rendition of the page, if the actual folder does not "require" SSL (check box under Directory Security, Enable SSL)

2) If The folder is REQUIRED to use SSL (check box in directory security is checked) the SSL encryption kicks in before the Ionics ISAPI filter runs and therefore you get the 403.4 forbidden error.

End of the day, this is what I am trying to accomplish. We have a massive web site with relative urls. For production, at the present moment we do not want to switch every url to use HTTPS, however we DO WANT these two folders to run under HTTPS.

Therefore, is my only option to NOT require SSL encryption at the folder level (In IIS)? It appears my RedirectRule won't kick off in time.

Or am I maybe doing this wrong?

Is it possible to have required SSL on a folder or virtual directory and then have IONIC redirect a non HTTPS link BEFORE SSL flags this forbidden error?

I don't understand where the 403.4 is coming from in step 2. What does it mean "the SSL encryption kicks in and therefore you get the 403.4". Does it ever work with an https URL when marked as "Requires SSL" ?
If you turn of IIRF, can you use an https scheme? then turning on the IIRF, you automatically get a 403.4 ? Really?

No, there's something I don't understand. Can you show me the relevant rules?

When Require Secure Channel is CHECKED, it appears the SSL process occurs before my ISAPI filter and you get the out of the box "this page requires Secure Socket Connection" IE error page. The page request is never logged in my log file, etc.

So unless I am doing this wrong, is this standard behavior/no way around this?

Basically I have presented the client with two different options. Static enforcement (folders have required SSL encryption) and using the custom 403.4 page approach (I have this working). OR for dynamic SSL swapping, IONIC and ISAPI.

Quick question for you. GREAT product by the way. For the dynamic SSL swapping, can you help me piece together the rules for this:

-If coming from port 80, and page within folder "folder1" or "folder2" redirect to https://......

-If NOT "folder1" or "folder2" and coming from port 443, re-write BACK to standard HTTP.

Make sense? I have a baseline for always redirecting to HTTPs, but I'm running into some issues going back or the other way. Basically if these two folders and 80, HTTPS, else back to HTTP.

I am using [I] for case insensitive searching, and the full urls are (obviously)
http://development.pia.com/buynow/f1/Cart, etc, I realize /buynow/f1 can be handled as a cleaner expression (2 folders before condition) but I doubt that has to do with the problem. The folders will
change when we go to production but thats not relevant

It works great besides one thing. And I cleared all my temporary files and cache to verify I wasn't going crazy but here is what is happening

FireFox: works great

IE: as you swap between, HTTP pages show the graphics fine, when you swap to HTTPS (the Cart and Security folder) the images do not render. This is baffling me :(. All images are relative urls and the browser is literally now not finding them,
I'm at a loss. All images are stored in the standard App Themes/Images folder.

I have checked over and over to validate its not consistent, but only IE, when swapping seems to lose the ability to show the images in HTTPS mode.

Any ideas? Using my old clunky method (shown the second thread) when I went to HTTPS I know I didn't lose the images, now its almost like it gets crossed up and can't resolve the images folder...

OK, another tid-bit of information, off localhost, the problem occurs less frequently (which is fine, off local host makes no difference to me). And it appears, if you refresh the page (F5) the image will appear. But even off the server it seems
to happen. Before I started using the ISAPI approach this didn't happen. Bizarre....

To troubleshoot this, I would look into the IIRF log for the requests for images, and the result of those requests (rewrite, no rewrite). Also, connect a debugging HTTP proxy to IE, something like Fiddler2, and you will very clearly be able to see
each HTTP GET that goes out of your browser, and the response it receives.

Mmmmmmm...well I'm not sure if that is case and unfortunately if it is, it has to do with this ISAPI flipping. End of the day, a
relative path that comes from an HTTPS-requested page will use the same protocol. Therefore when the request comes from port 443, relative urls are also run from the location. From port 80, they come from port 80.
Use strict SSL (at the folder level) and a custom 403.4 redirect page I do not have this problem. I would assume this is because my custom script in this page makes a full location replace or redirect, reloading the page in HTTPS.

I know FireFox and IE handle "Mixed" content prompting differently but typically I receive the annoying IE warning about "mixed" content and do I want to continue. I use Fiddler
all the time and I can look at what happening, but ths must be a direct relation to how we are trying to do this. The issue is mixed context, at the time of evaluating the request, the request is still in Port 80, which doesn't make a lot of sense, unless
the Images are being evaluated first by IIRF, then the page, the page is pushed, but the browser engine (IE in this case) still tries to pull the images from port 80...

Is there a way do an AND OR in IIRF?

If I add this to the condition: RedirectRule ^/buynow/f1/(Cart|Security|App Themes)/(.*)$

and starts working again, not saying it will, this completely puzzles me.

Then, sure, of course the 2nd rule will match. It uses port 443, so the RewriteCond returns TRUE. It has buynow/f1 as the first 2 segments in the URL path. The next segment is neither Cart nor Security. Therefore, it gets redirected.
The filter is doing EXACTLY what the rule says to do, which as far as I can tell, is EXACTLY what you described you wanted.

You asked: 'after the first redirect, wouldn't it stop running?" And I think you mean, for the first request, after RedirectRule #1 matches, won't IIRF stop processing rules? And the answer is YES, for that
request, IIRF will stop processing rules. But a redirect is a message back to the browser, which usually results in a new request from the browser, to the redirected URL. In this case the redirected URL (from the first rule) is on the same server,
and so IIRF is activated again, with a new URL. And there's a rule that matches the new URL, rule #2. And because it matches, IIRF returns a redirect.

If you think it's the right thing to do, you could exclude JPG and CSS from rule #2. It would look like this:

If port 443 (which means you are only in the Cart and Security sub folders) JPG and CSS will not be re-written to HTTP

ELSE everything, including CSS and JPG will be rendered as HTTP.

End of the day, if I am not in the Cart and Security folders I do not want the CSS and JPG to always pull from HTTPS. They should only pull from HTTPS if within these sub folders or the request itself is coming from HTTPS. So when I change pages,
all references are back to HTTP.

OK hang on. the RedirectRule, by itself, does not specify port 443 or 80 or anything. The port condition is specified in the attached RewriteCond, which you did not include. I'm going to assume you are interested in the rule and its condition
as I wrote it, like this:

and if there is another URL path segment and that segment is neither "Cart" nor "Security" (case-insensitive)

and if the final part of the URL ends in something that is neither JPG nor CSS (Case-insensitive)

...then redirect it to an http address of EXACTLY the same form.

If the incoming URL does not satisfy any of those conditions, then no redirect happens, with that rule.

Example: if the URL begins with /specials, then no redirect. It doesn't satisfy #2.

If the port is 80, no redirect. (stipulation #1) . If the URL path begins: /buynow/f1/Cart , then no redirect (reason #3). If the URL is 'https://development.pia.com/buynow/f1/App_Themes/Images/New_Cart_icon.JPG', then no redirect
(reason #4).

For other URLs you have to test it. You can reason about it all you want, but you need to test it to be sure.

Returning to the topic, enable "Require Secure Channel (SSL)" setting when using IIRF for HTTP->HTTPS redirection is not a bad idea, i think.
As Cheeso already wrote, we don't really need IIRF if all we are doing is redirecting for SSL. Of course, i mean setup where IIRF also performs many other tasks like HTTPS->HTTP redirection, rewriting urls and
so on. Let me explain advantage of this setting.

Clearly, we
must restrict access to "secure areas" (or rather sensitive information) over non-secure channel without fail. I think you agree with this. Therefore require SSL in IIS on folder/file level can treat as additional protection and may help
in the following situation. For example, we really can make a mistake in the complicated RedirectRule (or/and RewriteCond) expression, uncovered by our test unit (TestDrive). This mistake
can lead to lack of redirect and thus become a security threat if we don't use this setting.

Unfortunately, as far as i can understood (i am almost don't know neither C nor ISAPI), currently this setting not applicable due IIRF design.
(bits of tech info below) IIRF is doing rewrites on
SF_NOTIFY_AUTH_COMPLETE event. But before this event, IIS has already processed metabase properties (including
AccessSSLFlags of course) and block non-secure requests to secured location with 403.4 error. IIRF can't use
SF_NOTIFY_PREPROC_HEADERS as "single rewrite event" because at this stage not enough information for evaluate some rules
(physical path info, for example).
Perhaps, mix of above events can be used as a solution, but i doubt that it is worth the time.

Thank you for your comments and I do agree with you. This was basically a test driver or review of the options I was going to have. I absolutely, positively agree that the 403.4 redirect and letting IIS push this is the better solution for HTTP->HTTPS.
However, the original application deployment "idea" raised focused on "application level", for example ASP.net Master Page handling of when to rewrite to HTTPS and no folder level security settings in IIS at all, just the SSL cert was installed.

I immediately balked at this configuration because I believe in application transparency and I didn't want any higher level aspect (Java, Cold Fusion, PHP, ASP.net, you name it) checking urls and redirecting to HTTPS. When a real enterprise level application
goes from local development to shared development to production there should be no application level "checks" which push pages to HTTPS. Either before production hard wire your HTTPS access urls (you will have potentially mulitple copies of
your application depending on the architecture and deisgn, test environments should also use test SSL to validate all test cases), use IIS Custom Redirect and let IIS do this for you at the folder level, OR I was investigating the abilities of IIRF to do this
swapping, transparent to the application level.

Right now my development server is doing both (custom 403.4 redirect/IIS handling and ISAPI), or I've been swapping between approaches and testing. After a day or two of playing with IONIC
I did get the rewritecond and expressions correct, Cheeso started me off, I got rid of the check for extensions and such, basically following the logic of the standard IIS pipeline, page request, then secondary relative aspects come in, css,
jpg, js, etc. I have tested both (ISAPI swapping and IIS Custom Redirect) and both are working under all use cases I have set forth: (query strings at end of urls, folder names, etc.)

Thanks for your input and I do realize that IIS has already processed the AccessSSLFlags before IIRF kicks in, that was the firs thing I was trying to verify with this thread and it was verified for me.

OK hang on. the RedirectRule, by itself, does not specify port 443 or 80 or anything. The port condition is specified in the attached RewriteCond, which you did not include. I'm going to assume you are interested in the rule and its condition
as I wrote it, like this:

and if there is another URL path segment and that segment is neither "Cart" nor "Security" (case-insensitive)

and if the final part of the URL ends in something that is neither JPG nor CSS (Case-insensitive)

...then redirect it to an http address of EXACTLY the same form.

If the incoming URL does not satisfy any of those conditions, then no redirect happens, with that rule.

Example: if the URL begins with /specials, then no redirect. It doesn't satisfy #2.

If the port is 80, no redirect. (stipulation #1) . If the URL path begins: /buynow/f1/Cart , then no redirect (reason #3). If the URL is 'https://development.pia.com/buynow/f1/App_Themes/Images/New_Cart_icon.JPG', then no redirect
(reason #4).

For other URLs you have to test it. You can reason about it all you want, but you need to test it to be sure.

I'm using this rule but seems not to function well it does not filter the (.*) everything but (?!<(JPG|CSS) extensions, i have this:

Basically the problem is the same the last rule returns to http, when you're not in the ssl folder, now if you're in ssl theres som relative paths included in the folder /include, but the rule only sets https to folder /priv.

In detail when you´re https, and theres a link to include menu.js in the path /include/menu.js, the last rule returns it to http beause it isnt in the priv folder and gives you a mixed content.

Now i want to ignore this include/*.css, *.jpg and *.js when it's on ssl don't change it to regular http.

I'm not able to understand what you are saying. I can read the words, but I don't understand what you mean.

I think you are lacking some punctuation. It would be helpful if you gave me some examples, instead of the description, or in addition to the description.

What does it mean when you say: "the problem is the same the last rule returns to http, when you're not in the ssl folder," Can you give me an example of that? What URL do you send in, and what URL do you get out?
And what do you expect to get out, and how are the two different ? IF you can be vevry explicit with me, I'm sure I'll understand better.

I have the same questions around this statement: "now if you're in ssl theres som relative paths included in the folder /include, but the rule only sets https to folder /priv." I think that is a separate statement, but
I'm not sure because it was attached to the prior statement. But here again, if it is a separate observation, you need to give me a concrete example: what URL do you send in, what results do you see, what results do you expect, and how do they
differ?

"Now i want to ignore this include/*.css, *.jpg and *.js when it's on ssl don't change it to regular http."

I think you are confusing a few things. End of the day, are you swapping between https and http for all pages, certain folders, etc? I think the dicussion we had earlier in this thread where we talked about whether to use rewrite at all, or just IE SSL
enforcement is good to review again.

You need to look at this as where is the parent request coming from - - port 443 or port 80. In theory, if you have developed with relative urls you should NEVER been trying to swap your images, javascript or anything of the like in the first place.

-MyRandomPage.Aspx - Top Request

-favicon.ico - - subsequent request

-folder\TheScript.js - - subsequent request

-MyImage.jpeg - - subsequent request

And all other components until everything on "MyRandomPage.aspx" is completed.

Therefore you want to check first what port you are coming from. Then if within some folder (if you have that condition) and request file name ends with /or file extension ends with (x) but also optionally contains query strings redirect.
Where (x) in this case is .html, .aspx whatever. Now all subsequent requests after (your icos, scripts within that page) are already being pushed through the 443 port, so you don't do anything with them. To go back to HTTP its again similar but
now your check is if PORT 443. You need to get the top of the request chain and swap, from there, all the subsequent requests are already on port 80 or port 443

I have used IONIC IIRF for swapping between SSL and port 80 for specific folders and I'm also using the IE Enforcement approach. Either should work for you, just re-evaluate what you are trying to do.