#1 2014-07-14 04:43:21

avista
Member
Registered: 2014-01-06
Posts: 63

Weak Authentication Failure

Using the Project14ServerHttpWeak sample, I'm unable to get weak authentication working.

http://localhost:888/root/auth?UserName=Admin

Returns:

{
    "result": "386291780+89fe797742fea15af86f0b9c260629ecd11e7ffddb2c500cd667cfea4dcd7128",
    "logonname": "Admin"
}

Subsequent calls after authentication using:

http://localhost:888/root/calculator.add?n1=5&n2=5&session_signature=386291780

or

http://localhost:888/root/calculator.add?n1=5&n2=5&session_signature=386291780+89fe797742fea15af86f0b9c260629ecd11e7ffddb2c500cd667cfea4dcd7128

or

http://localhost:888/root/calculator.add?n1=5&n2=5&session_signature=89fe797742fea15af86f0b9c260629ecd11e7ffddb2c500cd667cfea4dcd7128


All fail with:

{
    "ErrorCode": 403,
    "ErrorText": "Forbidden"
}

What am I doing wrong here?

Thanks

Last edited by avista (2014-07-14 04:45:13)

Offline

#2 2014-07-14 07:02:06

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,659
Website

Re: Weak Authentication Failure

The SessionID returned by the Auth method is in decimal, whereas the session signature expects the corresponding hexadecimal value.
See TSQLRestClientURI.SessionCreate() in mORMot.pas or TSQLRestAuthentication.SetSessionID() in SynCrossPlatformREST.pas.
The SAD pdf wrongly states that the returned value is hexadecimal, whereas the session is returned as integer.

So, when 386291780 is returned, you have to write ?session_signature=17065844 at URL level, since $17065844=386291780.

BTW, why not use the Delphi client?

Offline

#3 2014-09-09 21:21:53

avista
Member
Registered: 2014-01-06
Posts: 63

Re: Weak Authentication Failure

Revisiting this issue, I noticed that while I need to specify the session_signature as a hexadecimal value in the URL when calling service functions, logging the user out as described in 19.1.2.2. Session handling:

When the Client is about to close (typically in TSQLRestClientURI.Destroy), a GET ModelRoot/auth?UserName=...&Session=... request is sent to the remote server, in order to explicitly close the corresponding session in the server memory (avoiding most re-play attacks).

requires that instead of using 'session_signature=', I need to use 'session=', and the code expects a decimal value:

function TSQLRestServerAuthentication.AuthSessionRelease(
  Ctxt: TSQLRestServerURIContext): boolean;
var aUserName: RawUTF8;
    aSessionID: cardinal;
    i: integer;
begin
  if UrlDecodeNeedParameters(Ctxt.Parameters,'Session') then begin
    // GET ModelRoot/auth?UserName=...&Session=... -> release session
    while Ctxt.Parameters<>nil do begin
      UrlDecodeValue(Ctxt.Parameters,'USERNAME=',aUserName);
--->  UrlDecodeCardinal(Ctxt.Parameters,'SESSION=',aSessionID,@Ctxt.Parameters); <-----------------------------------------------
    end;
    if (fServer.fSessions<>nil) and
       // allow only to delete its own session - ticket [7723fa7ebd]
       (aSessionID=Ctxt.Session) then
      for i := 0 to fServer.fSessions.Count-1 do
        with TAuthSession(fServer.fSessions.List[i]) do
        if (fIDCardinal=aSessionID) and (fUser.LogonName=aUserName) then begin
          fServer.SessionDelete(i,Ctxt);
          Ctxt.Success;
          break;
        end;
    result := true;
  end else
    result := false;
end;

This seems inconsistent to me...and makes it confusing for the developer that's using my API.

Perhaps at the very least, TSQLRestServerAuthentication.AuthSessionRelease() could be made virtual so I could override its functionality?

Thanks

Offline

#4 2014-09-10 07:17:01

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,659
Website

Re: Weak Authentication Failure

Conversion to/from decimal/hexa is confusing a developer?
This is a number, not a token.

I've added the possibility to use the hexadecimal session value for GET ModelRoot/auth?UserName=...&SessionHex=... method-based service to release a session, in addition to &Session=... parameter.
See http://synopse.info/fossil/info/24954e1126

But there are other parts of the protocol where we return a session as decimal value, not hexadecimal value.
For instance, when the session is created.

Offline

#5 2014-09-10 22:12:24

avista
Member
Registered: 2014-01-06
Posts: 63

Re: Weak Authentication Failure

Conversion to/from decimal/hexa is confusing a developer?

It is when it's not consistent:

- Create session and return a decimal number X
- Authenticate a session and require 'session_signature=' X to be in hexadecimal
- Close a session and require 'session=' to be decimal

This is a number, not a token.

The value that is passed via 'session_signature='/'session=' seems to be a token of sorts, so could you please explain what you mean by the difference?

Thanks for adding 'SessionHex=', but IMHO, it would be more consistent to either always use hex or always use decimal. smile

Last edited by avista (2014-09-10 22:24:28)

Offline

#6 2014-09-11 06:00:14

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,659
Website

Re: Weak Authentication Failure

I do not want to introduce breaking change for a matter of taste implementation detail, especially when it is never seeable from the end user.

We will see what we could do.

Offline

Board footer

Powered by FluxBB