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
 

18 hours ago, Angus Robertson said:

i have made RFC1123_StrToDate more robust with error handling, it will be in SVN later today with other changes.

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