0

How could this be implemented?

I'm not sure if it's possible to use the various flask related libraries as they use python decorators - and I don't have access to the Flask routes.

My solution would be to manually get the headers, and parse the authorization string manually. But I'm actually not to sure what format the Authorization follows - is there some library that can handle this complication for me?

Chris Stryczynski
  • 30,145
  • 48
  • 175
  • 286

2 Answers2

3

requirements.txt:

basicauth==0.4.1

And the code:

from basicauth import decode


encoded_str = request.headers.get('Authorization')
username, password = decode(encoded_str)

if (username == "example", password == "*********"):
    authed_request = True
Chris Stryczynski
  • 30,145
  • 48
  • 175
  • 286
0

The Cloud Functions (CFs) are primarily designed for executing simple, standalone tasks, not complex applications.

The recommended CF access control method is based on service accounts and IAM. From Runtime service account:

At runtime, Cloud Functions uses the service account PROJECT_ID@appspot.gserviceaccount.com, which has the Editor role on the project. You can change the roles of this service account to limit or extend the permissions for your running functions.

This access control method is enforced outside of the actual CF execution, so you don't need to worry about authentication in the CF code - you already know it can only be executed using the respective service account credentials.

Yes, it might be possible to use a custom authentication scheme similar to the one(s) use in more complex applications, but it won't be trivial - it's not what CFs were designed for. See the somehow related When to choose App Engine over Cloud Functions?

Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97
  • The URL is publicly available - not sure how service accounts provide any authentication in this manner. – Chris Stryczynski Nov 16 '18 at 23:54
  • Ah, you mean on the ingress side. I imagine the IAM checks for the `cloudfunctions.functions.call` permission is done at the CF trigger level. So if the trigger is HTTP, yes, the URL is public, but it's in the Google-owned `cloudfunctions.net` domain, so it's easy to do the IAM check after receiving the HTTP request but before actually invoking the CF. So you won't need to actually do anything inside the CF code itself, you just need to take care at configuring the CF and IAM roles and permissions. – Dan Cornilescu Nov 17 '18 at 04:10
  • I still don't understand why this has anything to do with HTTP's "Basic Access Authentication"? – Chris Stryczynski Nov 17 '18 at 09:16
  • I guess what I'm trying to say is that I see no point in attempting to parse/use the basic authentication info in the CF code. The info is either missing or static since a particular CF is always executed in a Google-curated environment, by the same identity/user. – Dan Cornilescu Nov 17 '18 at 14:13
  • It is sent in the HTTP request as an HTTP header - so with that I can check if it matches a username and password. – Chris Stryczynski Nov 17 '18 at 14:26