lindenR

Angus ... doing more code and the Google PK (the correct one) is RS256 not sure which key that one i was referring to was (juggling Azure/okta/and Google at the moment)

OOPS Missed that later on ... this key is a a Google supplied one that they want to use as a RS256 signature ... https://developers.google.com/identity/protocols/OAuth2ServiceAccount so I guess yes :) Using a jsigRsaPss256 key as a jsigRSA256 would logically seem to be reasonable (however I'm NO authority on this stuff) but even so the exception raised is not helpful as the length is correct just a mismatch of types maybe a optional _AllowUpClass : boolean = false so 774 becomes something like if (f_EVP_PKEY_bits(PrivateKey) < 2048) then Raise EDigestException.Create('RSA private key 2,048 or longer required') else if NOT ((keytype = EVP_PKEY_RSA) or ( _AllowUpClass and ( keytype in [ NID_rsassaPss, other rsaClasses ]))) then Raise EDigestException.Create('NOT a RSA private key') ... anyway thanks for getting back

The test of an RSA key at line 774 in OverbyteICSSSLJose displays a misleading message if (keytype <> EVP_PKEY_RSA) or (f_EVP_PKEY_bits(PrivateKey) < 2048) then Raise EDigestException.Create('RSA private key 2,048 or longer required'); My key length is 2048 however it fails the keytype test as the key is 912 ie NID_rsassaPss = 912; // V8.50 RSASSA-PSS not 6 as expected by this test ...

Apologies - a pair of stuffups caused this - in my code I was calling sendDoc twice and in the testing I was using the wrong dir and seeing cached files 😞

I'm getting corruption on serving up image files either - old internet style top say 1/4 of image is correct then some noise and then Black (or what ever depending on browser) Images vary from 80k to 2.4M and are similar in % displayed To demonstrate / reproduce I edited the HTML is the overByteICSWebSevr sample @1253 Image is in the TemplateDirEdit directory and my added HTML is '<img src="CustomLogo.jpg" alt="Logo" />' + I put this after the </FORM> tag in CreateVirtualDocument_ViewFormUpload this was the only change to the sample code current check out is 1440 - v8.63 Part 5

line 3940 (current SVN) S := MyIniFile.ReadString(section, 'NostEnabled', ''); HostEnabled=True

Perfect ... thanks

The Data that is firing the exception is Expires: 0 I have observed this in commercial web data - Okta / Azure - in my case I'm getting 6 exceptions in a OAuth2 + Data call so even a check for data length before the call would negate exception on "normal" data BTW I'm more concerned with the EncodeDate as that the cause of the exception (with 0 or -1 style data) ... I think that if the data was valid for date the time would normally be OK as you say headers are rarely invalid

Sorry unit that effects me is OverbyteIcsHttpProt; at line 3340 else if Field = 'expires' then begin { V8.61 } try FRespExpires := RFC1123_StrToDate(Data) ; except FRespExpires := 0 ; end ; end Fix that I've suggested is in OverbyteIcsUtils; at line 1370ish

here is the code for a RFC1123_TryStrToDate with some options {* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *} { RFC1123 5.2.14 redefine RFC822 Section 5. } { V8.62 optionally process time zone and convert to local time } {Linden ROTH modified to not raise exceptions on encode invalid Dates/Times} function RFC1123_TryStrToDate(aDate : String; UseTZ: Boolean = False) : TDateTime; var Year, Month, Day : Word; Hour, Min, Sec : Word; tzvalue: Integer; sign: String; tmpTime : TDateTime; begin if Trim( ADate ) = '0' then //or even just length < 13 begin result := 0; exit; end; { Fri, 30 Jul 2004 10:10:35 GMT } { Tue, 11 Jun 2019 12:24:13 +0100 } Day := StrToIntDef(Copy(aDate, 6, 2), 0); Month := (Pos(Copy(aDate, 9, 3), RFC1123_StrMonth) + 2) div 3; Year := StrToIntDef(Copy(aDate, 13, 4), 0); Hour := StrToIntDef(Copy(aDate, 18, 2), 0); Min := StrToIntDef(Copy(aDate, 21, 2), 0); Sec := StrToIntDef(Copy(aDate, 24, 2), 0); if not TryEncodeDate(Year, Month, Day, Result ) then begin result := 0; exit; end; if not TryEncodeTime(Hour, Min, Sec, 0, tmpTime ) then exit; //or - to 0 complete result // begin // result := 0; // exit; // end; //or - to ignore bad time but proceed // tmpTime := 0; Result := Result + tmpTime; { V8.62 check for time zone, GMT, +0700, -1000, -0330 } if NOT UseTZ then Exit; if Length(aDate) < 29 then Exit ; // no time zone sign := aDate [27]; if (sign = '-') or (sign = '+') then begin // ignore GMT/UTC tzvalue := StrToIntDef(copy (aDate, 28, 2), 0) * 60; if (aDate [30] = '3') then tzvalue := tzvalue + 30; if sign = '-' then Result := Result + (tzvalue / MinutesPerDay) else Result := Result - (tzvalue / MinutesPerDay); end; Result := Result - (IcsGetLocalTimeZoneBias / MinutesPerDay); end;

The functionality added in 6.81 in Added more header response properties: RespDateDT, RespLastModDT, RespExpires, RespCacheControl. Uses EncodeDate rather than TryEncodeDate in the utility function function RFC1123_StrToDate(aDate : String; UseTZ: Boolean = False) : TDateTime; would it not be more preferable to use the same functionality as used by function RFC3339_StrToDate(aDate: String; UseTZ: Boolean = False): TDateTime; and avoid response lines like 'Expires: 0' triggering unnecessary EConvertExceptions Linden ROTH