Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Http.sys questions
#11
Hi Magnus,

your redirect code looks correct to me. I'd just use StartsText() instead of ContainsText() when checking the URL for a match...

But it should work just fine
Reply
#12
Thanks for your answers Alexandre! First I will complete a number of tasks related to this project, then I will try with the new IW version. Regarding TLS 1.3, it is not required at the moment; I just want us to be one step ahead in case some major security issue is discovered in TLS 1.2. Besides the 2008 server, most of the other involved servers are 2012 R2 and when I google for enabling TLS 1.3 there, the answers I find is negative. We might want to do a server migration project anyway after this, and then we might as well use 2022 in the new servers.

Best regards

Magnus Oskarsson
Reply
#13
To be honest I think that is more plausible that they find a major flaw in TLS 1.3 than in 1.2.

TLS 1.2 is the evolution of 1.1, with all the security flaws fixed or remedied... TLS 1.3 is a new thing. After being on this road for some time now I think that new stuff is more subject to major unexpected flaws than things that evolve over time... The future will tell us anyway ;-)
Reply
#14
There's a lot of truth and wisdom there.

Version 3 of pretty much anything has been the sweet spot (1.0, 1.1, 1.2).

Version 1 - release, always a rush... but without features that were not quite ready.
Version 2 - rush out the features that weren't ready on V1.
Version 3 - Make it all work.

Version 4 - "now we can really make this thing cool" (aka "oops"... start the cycle over) (we should rewrite this whole thing)

Dan
Reply
#15
I agree with you both on the above, although the requirements we face from customers etc. are not always based on what is actually best...

FYI Alexandre: I just tested upgrading from IW 15.1.15 to the latest IW version (in evaluation mode). Our main web application (which does not include CGDevTools) compiled without issues, and it seemed like the shutdown issues I have mentioned earlier were gone! I need to do a more thorough test of the application, but so far it is very promising.

Note: As our old had expired, we have purchased new licenses (although not received them yet).

Best regards

Magnus Oskarsson
Reply
#16
Hi again. I have made some more test of our web applications with the latest IW version. Found some small issues that I was able to fix on our side. But there is one thing that worked in 15.1.5 that now no longer works. For security reasons, we sometimes change the response code to a redirect when the previous post may have contained sensitive information (such as login details). We have code like this (suggested by you Alexandre if I recall correctly):

Code:
procedure ChangeResponseCodeFromOKToRedirect(const URL: string);
begin
  WebApplication.Response.Code := 302;
  WebApplication.Response.AddHeader('Location', URL);
end{procedure};

procedure TerminateWithRedirectResponseCode(const URL: string);
begin
  WebApplication.TerminateAndRedirect(URL);
  ChangeResponseCodeFromOKToRedirect(URL);
end{procedure};

If I now call TerminateWithRedirectResponseCode(URL) rather than just WebApplication.TerminateAndRedirect(URL), I now get a ERR_RESPONSE_HEADERS_MULTIPLE_LOCATION error. Do you know how I can fix this issue?

Best regards

Magnus Oskarsson
Reply
#17
Is this a sync call?

I believe you can completely remove your ChangeResponseCodeFromOKToRedirect() call, can't you?

Short answer:

The TerminateAndRedirect process will set Code to 303 (which is more adequate than 302 and used in most parts of IW 15.2) and adds the header correctly.

Long complete answer:

TerminateAndRedirect has been reworked to be smarter and especially SAFER without user intervention.

Whenever you redirect to another root address (i.e. another site) a GET will always be used (so no sensitive data is ever POSTed to another site). POST redirect is only used when you are using the same root url (same IW application) and the data is needed (e.g. session info).

I believe you are pretty safe using TerminateAndRedirect() to another site
Reply
#18
Thanks for the explanation Alexandre!

(Yes, this was a sync call). Rather than removing it, I have modified my code so that it works with both older and newer versions of IntraWeb.

/Magnus
Reply
#19
I have now focused a bit more on the shutdown problems (access violations etc.) I mentioned earlier (when running with http.sys rather than Indy). When I tested our main web application with IW 15.2.49 I saw no such problems, neither when run as a service nor when run as an application. But with our two other web applications I still had the issues when running as an application. As they share much code I tried to sort out the differences. I noticed that we had IWStartHSys (and previously IWStart) placed differently in the project uses clause. In the ones where I saw problems I had it pretty high up in the list of units, after IWJclDebug and IWJclStackTrace, whereas it was further down the list in the main web application. And when I move this unit down in the list, the shutdown problems seem to disappear. Do you have an explanation for this? Is it recommended to have the unit absolutely last in the uses list?

Best regards

Magnus Oskarsson
Reply
#20
(01-27-2022, 07:45 AM)magosk Wrote: Thanks for the explanation Alexandre!

(Yes, this was a sync call). Rather than removing it, I have modified my code so that it works with both older and newer versions of IntraWeb.

/Magnus

Can you please let me know how you changed it? It may be important for me to understand what your issue was
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)