chore(console, api): soft and hard regexes for usernames #525

VojtaKai · 2025-07-29T06:18:40Z

Regular users can no longer use "apify" in their usernames. Admins still can.

jancurn · 2025-07-30T10:06:39Z

packages/utilities/src/utilities.ts

-export function isForbiddenUsername(username: string): boolean {
-    return !!username.match(APIFY_ID_REGEX) || !!username.match(FORBIDDEN_REGEXP);
+export function isForbiddenUsername(username: string, options: { isAdmin?: boolean, isApifier?: boolean } = { isAdmin: false, isApifier: false }): boolean {
+    return !!username.match(APIFY_ID_REGEX) || !!username.match(FORBIDDEN_REGEXP)


Why do we need isApifier ? IMO isAdmin check is sufficient, as 90% Apifiers are admins anyway - simpler => better

Apifier is a user with @apify email. The only reason is convenience when creating an apify test user, I assume. Is that correct @mhamas ?

IMHO it would make sense to remove this and rename "Apify test user" to something else (Internal test user?) to keep the same behaviour for test user as for users. It will simplify adding tests for this.

The option isApifier will be removed and apify test users will be renamed to internal users.

Cool. The fewer special cases the better

packages/consts/src/consts.ts

mtrunkat · 2025-07-30T11:17:32Z

packages/utilities/src/utilities.ts

-export function isForbiddenUsername(username: string): boolean {
-    return !!username.match(APIFY_ID_REGEX) || !!username.match(FORBIDDEN_REGEXP);
+export function isForbiddenUsername(username: string, options: { isAdmin?: boolean, isApifier?: boolean } = { isAdmin: false, isApifier: false }): boolean {
+    return !!username.match(APIFY_ID_REGEX) || !!username.match(FORBIDDEN_REGEXP)


IMHO it would make sense to remove this and rename "Apify test user" to something else (Internal test user?) to keep the same behaviour for test user as for users. It will simplify adding tests for this.

VojtaKai · 2025-07-30T12:07:04Z

packages/consts/src/consts.ts

    MAX_LENGTH: DNS_SAFE_NAME_MAX_LENGTH, // DNS-safe string length
-    REGEX: DNS_SAFE_NAME_REGEX,
+    REGEX: /^(?!.*apify)([a-z0-9]|[a-z0-9][a-z0-9-]*[a-z0-9])$/i,
+    ADMIN_REGEX: DNS_SAFE_NAME_REGEX,


@mtrunkat If I add the min and max length in the DNS_SAFE_NAME_REGEX, it might potentially throw weird errors in forms because in some cases, it is only necessary to match the expression but not the length.

Example: https://github.com/apify/apify-core/blob/develop/src/packages/schemas/src/key_value_stores.ts#L9-L15

Should I add the length there?

The advantage of separating DNS_SAFE_NAME_MAX_LENGTH and DNS_SAFE_NAME_REGEX is that you get better error messages: Xxx is too long vs. Xxx doesn't match regular expression

So I'd be careful with updating these constants that are used across our code base

BTW ther are 1,700 Actors that contain "apify" in their name - will these keep working ?

Very valid question. I need to investigate what actions are going to be affected by this but from my changes alone, I already know that updateActor (API PUT endpoint) will stop working IMMEDIATELY unless they change the actor name.

The other PR: https://github.com/apify/apify-core/pull/22269/files#diff-4b79096b13a59997f18f26ea5c1fedd7f620bfdd1f5c1268e08d3dfa11362cd2R265

We may give them a pass if the actor names already contains "apify" (they would still need to pass the less strict regex). If it is a new one, they will need to comply with the new regex.

Looking at the other PR, I don't have a very good feeling about this change, it can cause more problems than benefits...

The updateActor will not throw an error if the actor already had "apify" in its name -> https://github.com/apify/apify-core/pull/22269/files#diff-4b79096b13a59997f18f26ea5c1fedd7f620bfdd1f5c1268e08d3dfa11362cd2R263

Prod DB insights:
Actors with apify in the name: 1716

out of it managed by Apify: 15

managed by Apify and public: 4

managed by community: 1701

managed by community and public: 41

Original REGEX kept. New REGEX - RESTRICTED_REGEX - only applied in places where we want to make the change.

No current Actor which already has the substring "Apify" in their name or title will be affected --> https://github.com/apify/apify-core/pull/22269/files#diff-4b79096b13a59997f18f26ea5c1fedd7f620bfdd1f5c1268e08d3dfa11362cd2R263-R265
Only new actors will be affected and have to comply with the "no apify substring in actor name or title" requirement.

Hmm looking at the numbers, this is a problematic change; we can't enforce this for existing Actors because we disable users from updating them. But if they changed the technical names, the integrations break. So there is no good option for developers to solve this.

Let's discuss this in person? It will be faster.

That's a great point. Honestly I'm not convinced about the whole reasoning behind this change. It makes sense to prohibit use of "apify" in username to avoid confusion, but why in Actor names? We allow "amazon", "google", etc. no problem but ban "apify". But there are legitimate cases for third-party Actors having "apify" in the name, e.g. "apify-airbyte-integration" or "apify-store-scraper".

Altogether, let's just abandon this idea.

VojtaKai · 2025-07-30T12:08:16Z

packages/utilities/src/utilities.ts

-export function isForbiddenUsername(username: string): boolean {
-    return !!username.match(APIFY_ID_REGEX) || !!username.match(FORBIDDEN_REGEXP);
+export function isForbiddenUsername(username: string, options: { isAdmin?: boolean, isApifier?: boolean } = { isAdmin: false, isApifier: false }): boolean {
+    return !!username.match(APIFY_ID_REGEX) || !!username.match(FORBIDDEN_REGEXP)


The option isApifier will be removed and apify test users will be renamed to internal users.

jancurn · 2025-07-30T12:29:08Z

test/utilities.test.ts

            expect(utils.isForbiddenUsername('karel.novak')).toBe(false);
+
+            // Regular user vs Admin
+            expect(utils.isForbiddenUsername('aPifY')).toBe(true);


Pls let's test cases where Apify is in the middle of the string

jancurn

As discussed in #525 (comment), let's abandon prohibiting "apify" in actor names, it solves a problem that doesn't even exist and opens a lot more actual problems.

jancurn

Great, thanks

gippy

As mentioned on slack. I do not believe that this change should be done here and should instead be done directly in console backend. This is open source package + it is used on the web. There is no reason why people should know that we allow apify for admins and it would be much cleaner if we just had a condition for apify directly in the update username method. Which is the only place it is used except for the web.

As for the web, If we keep this as it is, and you merge it, you also need to update the logic there, because on the web it's used to check in routing if the path is a valid username, to redirect users to correct user profile pages.
Here: https://github.com/apify/apify-web/blob/e410bac5e1f2943b37b5d51c43cba2d5ecf2c5bc/src/server/lib/helpers.ts#L93
So this path: https://apify.com/apify would no longer work

And to fix it on the web you would have to call it with { isAdmin: true } which is weird.

So I think either you should move this logic (checking apify) to backend, or rename the argument to be isApifyAllowed instead of isAdmin so that it's clearer when used on the web.

VojtaKai · 2025-08-01T06:29:55Z

Thank you for the insights. The option will be removed and the condition will be moved to backend.

…actors-for-non-admins

soft and hard username and actor regexes

562bdb7

VojtaKai changed the title ~~chore(console, api): soft and hard username and actor regexes []~~ chore(console, api): soft and hard username and actor regexes Jul 29, 2025

github-actions bot assigned VojtaKai Jul 29, 2025

github-actions bot added this to the 120th sprint - Cash & Community team milestone Jul 29, 2025

github-actions bot added the t-c&c Team covering store and finance matters. label Jul 29, 2025

chore(console, api): soft and hard username and actor regexes

1689231

github-actions bot added the tested Temporary label used only programatically for some analytics. label Jul 29, 2025

VojtaKai added 2 commits July 29, 2025 16:51

chore(consts): actor names and titles cannot contain "apify"

54addb2

chore(consts): isApifier option in isForbiddenUsername

55b6787

VojtaKai requested review from mtrunkat, jancurn, gippy and mhamas July 30, 2025 10:03

jancurn reviewed Jul 30, 2025

View reviewed changes

VojtaKai changed the title ~~chore(console, api): soft and hard username and actor regexes~~ chore(console, api): soft and hard regexes for username and actor name / title Jul 30, 2025

mtrunkat reviewed Jul 30, 2025

View reviewed changes

chore: simplified regexes, removed isApifier

0f2d231

VojtaKai commented Jul 30, 2025

View reviewed changes

jancurn reviewed Jul 30, 2025

View reviewed changes

VojtaKai added 3 commits July 30, 2025 16:02

chore: test apify in the middle of a string

14a4e8c

chore: non deceiving test username

bffc413

chore: extended regexes, original kept

04e7680

VojtaKai requested review from jancurn and mtrunkat July 31, 2025 07:28

jancurn requested changes Jul 31, 2025

View reviewed changes

chore: return to old actor regexes

2f0027e

VojtaKai requested a review from jancurn July 31, 2025 13:15

jancurn approved these changes Jul 31, 2025

View reviewed changes

gippy reviewed Jul 31, 2025

View reviewed changes

VojtaKai added 2 commits August 1, 2025 10:11

fix: changes reverted for isForbiddenUsername

c44922a

fix: reverted isForbiddenUsername tests

9759601

mtrunkat approved these changes Aug 6, 2025

View reviewed changes

Merge branch 'master' into chore/prohibit-keyword-apify-in-usernames-…

908b2b2

…actors-for-non-admins

VojtaKai changed the title ~~chore(console, api): soft and hard regexes for username and actor name / title~~ chore(console, api): soft and hard regexes for usernames Aug 11, 2025

VojtaKai merged commit 91af634 into master Aug 11, 2025
10 checks passed

VojtaKai deleted the chore/prohibit-keyword-apify-in-usernames-actors-for-non-admins branch August 11, 2025 11:05

chore(console, api): soft and hard regexes for usernames #525

chore(console, api): soft and hard regexes for usernames #525

Uh oh!

Conversation

VojtaKai commented Jul 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VojtaKai Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VojtaKai Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jancurn Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VojtaKai Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VojtaKai Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VojtaKai Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mtrunkat Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VojtaKai Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jancurn left a comment

Choose a reason for hiding this comment

Uh oh!

jancurn left a comment

Choose a reason for hiding this comment

Uh oh!

gippy left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VojtaKai commented Aug 1, 2025

Uh oh!

Uh oh!

Uh oh!

VojtaKai commented Jul 29, 2025 •

edited

Loading

VojtaKai Jul 30, 2025 •

edited

Loading

VojtaKai Jul 30, 2025 •

edited

Loading

jancurn Jul 30, 2025 •

edited

Loading

VojtaKai Jul 30, 2025 •

edited

Loading

VojtaKai Jul 30, 2025 •

edited

Loading

VojtaKai Jul 31, 2025 •

edited

Loading

mtrunkat Jul 31, 2025 •

edited

Loading

VojtaKai Jul 30, 2025 •

edited

Loading

gippy left a comment •

edited

Loading