Cloudflare Access Beta Feedback

@pkernstock thanks so much for the very thoughtful feedback.

Providing links for the identity provider - yes! That change will go out today.

Renaming the Cloudflareaccess subdomain - great feedback.

access tab reloading - yes, 100% agreed, we’re going to fix that.

needing to change the callback - you’re totally right, we will fix that.

portal customization hex code - would never have thought of that, that’s great.

the log viewer time - good catch, will fix.

further explanation - we will add, that’s good feedback.

autocomplete - great idea

any url - stay tuned.

Thanks again! Very useful.

1 Like

Extremely interesting feature. I signed up so I could try to add some extra protection to a path on our site. Unfortunately it only seems to accept subdomains via “Application Domain” at this time. Hopefully you will let us select paths on the main domain soon, such as

@GI-Eaton - yes! that’s coming soon.

Is there an issue with Google Apps integration right now? Followed all the instructions, added my email as an allowed property, but it’s not authenticating. This is after I click “Google Apps” and enter my password.

Access Error

Hey @GI-Eaton!

You have run into a new UI bug. If you try to create a GSuite integration during the setup flow the modal is closed before you can fully finish the setup. We have fixed this behavior and it should be in a release soon.

As a workaround for now, try doing this. Once you are on the main access page and are not in the setup flow, create a new GSuite Identity Provider with the same credentials. You should see the second setup screen this time, which you will need to click through and follow to finish setting up. Once you have set up this new identity provider. Go ahead and delete the older one.

Apologies for this and thanks a bunch for letting us know!


@solidsnake yep that’s normal. Once you setup your initial identity provider you should be able to modify your authentication domain (that original text field you saw) to whatever you want.

1 Like

Spot on with that diagnosis! I got it to work.

1 Like


  1. When clicking the link, it ends up saying “Successfully setup your new enterprise connection!”. Does this mean that once out of beta, Access is going to be an Enterprise only feature? If that’s a yes, what features will be available to the other account levels?
  2. I believe “Google Apps” on the Access login page should be renamed. That’s an older term Google phased out in favor of G Suite.
  3. When is the “Consent Screen” that we configure while setting this up shown exactly? Didn’t appear when I logged in.

Great question @GI-Eaton. The feature will be for everyone, not limited to enterprise. The copy as you pointed out is a bit confusing. We differentiate between enterprise identity providers (i.e. GSuite) and social identity providers (i.e. Facebook). That’s what that copy referred to.

Google Apps - good point. Fixing.

I don’t think it is shown as part of the OAuth flow.

1 Like

You’re right, but some info is actually shown here after you log in:

Surprised Google doesn’t ask for permission to add the app to your account, though. I wonder why that is.


You’re welcome, @dani!

Some more thoughts:

  • Logs - History: It would be cool to see somewhere how long logs are being saved.
  • Logs - Recent users: On the other log-tabs it’s possible to click on it to get further information, on “Recent users” don’t. It displays the hand cursor to show something can be done when clicking on it - nothing happens actually. What about showing some more possible information here as well? (UserAgent? Used provider?)
  • Adding provider - PreChecks: Maybe a bit more complex to build, but any kind of pre-checks if the provided identity information are correct would probably help preventing any upcoming issues (e.g. when re-configuring and locking everyone out, etc)
  • Logs - Recent users: Logs like "Access Requests" and "Policy changes" are separated by domain - why “Recent users” isn’t? Is this an intended behavior?
  • Adding provider - Custom: Some applications offers to host own oauth services, wouldn’t it be cool to add custom identity providers? For example self-hosted GitLab installations.
  • Access Policies/Logs separated by site: I was just wondering why my access policies and logs aren’t visible anymore - just noticed: I’ve switched over to any other domain. So when Policies and Logs are based on domain I’d suggest making it clearer that the user is currently only seeing data for domain.tld - for example: Control which individuals have access to applications on your $domain.tld$ domain., or Verify policy accuracy by monitoring user access logs, and view history of policy changes for domain $domain.tld$.
  • Logs - Search: Somehow the search functionality seems to be broken a bit? I’m often getting edgeauth.api.error.internal_server_error (Code: 10001) and 429 - TOO MANY REQUESTS of any Sentry API:
  • Logs - Search - Animation: In case search takes a bit any “loading” animation would be probably a good choice, to signalize the users that something happens already.
  • Access Policies - Create: When I’m creating one more access policy with the same used domain as an other, I’m getting a very (for end-users) ugly error message: violates unique constraint: Key (domain, org_id)=(sub.domain.tld, 338) already exists. (Code: 9999).
  • Access Policies - Create - AppName: Wouldn’t be "Policy Name" a better name instead of "Application Name"? (and also being unique as subdomain across all policies?)
  • Access Policies - Listing: On the listing of all created access policies there are two dashes between "Application Name" and "Subdomain". Is this intended?
1 Like

How do you block a particular URL only? That is I imagine the most common scenario for this would be blocking wordpress login URL. Are there are instructions on setting this up?

Also is this just mean to for internal projects, versus say staging site, where you would share a site url with each client and would provide them a user name and password (since can’t count on clients having g suite.

This is amazing and revolutionary. My friend was instantly approved for the beta when he signed up earlier today, but it seems users now have to wait. That’s too bad :frowning:

Awesome @pkernstock!

Log history - great idea. Adding.

Recent user information - I’m curious if that list ends up being useful at all, or if you would only look at Access request logs. And it should be separated by domain, you found a bug.

Pre-checks - yes, we’re trying to figure out what we can do there.

Custom auth provider - great idea.

Logs per domain - yes, we can totally make that more apparent.

Great catch with the log search, we’re on it. Animation is a good idea too.

Policy Name - very possibly. It displays on the login page so it should describe whatever is behind the login page.

1 Like

That’s great to hear @TallGuysFree! We just enabled the beta for you. You can get started at Enjoy!

1 Like

@chris11 - path support is coming soon!

You can absolutely use this for a staging site. If your client has a facebook account, a github account or a gmail account you can set up one of those as the identity provider and allow the client to access.

1 Like

I’ve found some more points for you, @dani :slight_smile:

  • Adding access policy - Subdomain naming: In the subdomain field you’ve to enter a subdomain ending with the own domain. To make it more user-friendlier: Allow entering a subdomain and add a selectbox with the possible ending domains available for selection (like "Login Page Domain")
  • Adding access policy - Property: There’s a small typo: GitHub Organization (with uppercase H) :wink: (and on the edge UI site)
  • Logs - Policy Changes: When deleting an access policy the first column in the logs is empty. It would be nice to see the actual deleted policy rule (subdomain name, or policy name)
  • Logs - AccessRequests/PolicyChanges: Is searching based on “domain” useful here? What about searching for domain or email as well?
  • Customization - Preview: When loading the "Access"-tab it loads the icon set in the customization dialog, everytime. I would consider this a bit as “unnecessary” traffic each time. I’d suggest just putting a placeholder-icon in the auth-UI preview.
  • Customization - Background: What about allowing to specify a background image than just selecting a color code? (To better change the design to corporate graphic schemes)
  • EdgeAuth - Providers: Providing any kind of customization of the listed providers (colors, selecting one favorit provider to highlight it, appending short text / manual provider renaming, etc). Probably useful for larger companies who are having different providers to make it easier for their users to select the right one.
  • EdgeAuth - Meta Title: The logo down below says “Cloudflare Access”, the title “Cloudflare Auth”. Intended?
  • Analytics: For some day in the future. Some analytics/cool graphs about Access-logs, like "Succesful authorizations", or "Failed authorizations".
  • EdgeAuth - Facebook: When clicking on Facebook provider and when clicking on “Not now” to abort the login, I get redirected to a site just containing a JSON output. A simple error page would be fine instead. [Added with edit]
1 Like

@dani Thanks I look forward to trying it out once path support is enabled, to block access to WordPress admin. I don’t see it working as a staging site solution for us at least, as we have countless clients of all walks of life, so they would be guaranteed to not have Github, most would not have gmail, and while many may have Facebook can’t count on that as well as them not wanting to signin with their personal Facebook account to a work site. So would need also need a traditional user name and password solution to know that we wouldn’t run into issues. Still will be neat for any internal work where we always know the audience.

1 Like

+1 for a custom Cloudflare identity provider that will let you create accounts in the Cloudflare web interface for clients to log in, without needing to use a third party service. Doesn’t have to be fancy, a username and password would probably be fine.

1 Like

The access page has 2 HSTS headers when there should only be 1.