@nullstyle do you know if there are any plans to change the general behavior w/r/t this? At current, it looks like either you implement ask_user and that is the source of truth or you use the /allow_access API—the two are totally separate ways of authorizing info and don’t really have any interplay with each other.

I can imagine intended or deprecated scenarios (I don’t really know the history/genesis of this feature) where you whitelist/blacklist w/ the API and fall back to the callback or something, but that certainly doesn’t seem to be how it works now.

Just trying to understand the direction this is moving in (if any) for documenting.

ask_user is a fallback in case allow_access fails. So it would be:

request_comes_in()
{
   if(allow_access)
   {
       return: user info
   }else if(ask_user)
   {
         return: user info
   }
   return: no info
}

Hmmm, it could be that I’m reading it wrong, but it seems like the only time the database is checked (i.e. we look at the allow_access path) is if ask_user is unimplemented: https://github.com/stellar/bridge-server/blob/master/src/github.com/stellar/gateway/compliance/handlers/request_handler_auth.go#L202-L236

…so it can’t really fall back. Is what you’re describing the intended behavior and the current implementation just isn’t correct?

I haven't looked at the implementation. What I described is how it should work

It works exactly as @jedmccaleb explained. Excerpt from compliance/handlers/request_handler_auth.go:

if rh.Config.Callbacks.AskUser == "" {
  // There is no ask_user callback specified
  // Check if domain or user*domain is in allowed table
  if "record exists in a DB" {
    return compliance.AuthStatusOk
  } else {
    return compliance.AuthStatusDenied
  }
} else {
  // Send request to ask_user callback
  if "callback returned OK" {
    return compliance.AuthStatusOk
  } else {
    return compliance.AuthStatusDenied
  }
}

The readme for compliance currently states that if the ask_user callback is not specified, “then the customer information won't be given to the other FI.” This isn’t actually true—it falls back to users and domains that have been whitelisted using the allow_access endpoint.

Yeah, you're right. This sentence is true, however, when AllowedFi/AllowedUser tables are empty. So we should rewrite this single statement.

At current, it looks like either you implement ask_user and that is the source of truth or you use the /allow_access API—the two are totally separate ways of authorizing info and don’t really have any interplay with each other.

These two options seem similar but ask_user callback gives you more control. The main difference is that ask_user callback is actually meant to ask user whether she wants to accept a payment. Besides other fields, we're sending amount, asset and note attached to a payment. /allow_access simply saves domain or user*domain of the sender and when a payment arrives, compliance server only check the sender field.

Excerpt from compliance/handlers/request_handler_auth.go

Right! I started this issue as a result of reading that code :)

I think the confusion here is that we each understood @jedmccaleb's answer very differently. He wrote:

if (allow_access) {
  return: user info

Which I interpreted like:

if (user_or_domain_is_in_db) {
  return: user_info

And you interpreted like:

if (should_check_db) {
  return user_or_domain_is_in_db ? user_info : auth_denied

For my part, I definitely thought he meant the former, but now I don’t know. Can you clarify, @jedmccaleb?

If the latter, everything about the code is 👍. If the former, it seems like there’s a bug in the code in addition to the documentation issue.

Anyway! I can do a PR for clarifying all this in the readme, but I want to make sure the current state of the code matches the intended design (our point of confusion above). If it does not, I should probably hold off, because documenting the current state of affairs will set up wrong future expectations for users and documenting the intended state of affairs would lead someone to think they can use the service in a way that won’t actually work today :P

OK, I think I understand now. I checked the Compliance Server design doc and there's a following sentence:

If ASK_USER_CALLBACK is not set then if the FI can't be found in the DB for this user then info_status will be no denied
If the sending FI does show up in FIAllows or the UserAllows table then call FETCH_INFO_CALLBACK to get the info to return to the requester.

It's not clear and can be implemented in at least two different ways. So yeah, let's wait for Jed to clarify.

PS. @Mr0grog I can share this doc with you but I don't have your email. Send me a message :)

Yeah Rob's first interpretation is correct. To rewrite your code bartek:

if "record exists in a DB" {
    return compliance.AuthStatusOk
  } else {
     if rh.Config.Callbacks.AskUser != "" {
            // Send request to ask_user callback
            if "callback returned OK" {
                return compliance.AuthStatusOk
             }
        }
       return compliance.AuthStatusDenied
  }

but don't fix it till scott lands his changes