Replace isStorefrontPasswordProtected with API call #5166
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We were previously determining whether or not a storefront was password protected by making a HTTP request to the storefront and checking the response status. This worked for us in the past but is a known fragile piece. We've now shipped the ability to query whether the storefront is password protected directly in the Admin API so we no longer need to guess. This replaces all instances of `isStorefrontPasswordProtected` with the updated API call.
Differences in type declarationsWe detected differences in the type declarations generated by Typescript for this branch compared to the baseline ('main' branch). Please, review them to ensure they are backward-compatible. Here are some important things to keep in mind:
New type declarationspackages/cli-kit/dist/cli/api/graphql/admin/generated/online_store_password_protection.d.tsimport * as Types from './types.js';
import { TypedDocumentNode as DocumentNode } from '@graphql-typed-document-node/core';
export type OnlineStorePasswordProtectionQueryVariables = Types.Exact<{
[key: string]: never;
}>;
export type OnlineStorePasswordProtectionQuery = {
onlineStore: {
passwordProtection: {
enabled: boolean;
};
};
};
export declare const OnlineStorePasswordProtection: DocumentNode<OnlineStorePasswordProtectionQuery, Types.Exact<{
[key: string]: never;
}>>;
Existing type declarationspackages/cli-kit/dist/public/node/themes/api.d.ts@@ -22,4 +22,5 @@ export declare function metafieldDefinitionsByOwnerType(type: MetafieldOwnerType
name: string;
category: string;
};
-}[]>;
\ No newline at end of file
+}[]>;
+export declare function passwordProtected(session: AdminSession): Promise<boolean>;
\ No newline at end of file
|
Coverage report
Show new covered files 🐣
Show files with reduced coverage 🔻
Test suite run success1996 tests passing in 903 suites. Report generated by 🧪jest coverage report action from 222bc76 |
jamesmengo
reviewed
Jan 7, 2025
|
|
||
| const redirectLocation = new URL(response.url) | ||
| return redirectLocation.pathname.endsWith('/password') | ||
| export async function isPasswordProtected(session: AdminSession): Promise<boolean> { |
There was a problem hiding this comment.
I wish we had a better distinction internally between the theme-access password and the storefront password.
I've gotten confused by this before, which is why I chose the extremely verbose name. I'm ok with this name.
I'll leave this comment for future devs for the case that someone else is reading this in the future due to naming confusion,
There was a problem hiding this comment.
I think using "Password Protected" makes it clear to me but I see what you mean. Ideally anytime we're referring to the --password flag we're calling it more like a "token".
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WHY are these changes introduced?
We were previously determining whether or not a storefront was password protected by making a HTTP request to the storefront and checking the response status. This worked for us in the past but is a known fragile piece.
We've now shipped the ability to query whether the storefront is password protected directly in the Admin API so we no longer need to guess. This replaces all instances of
isStorefrontPasswordProtectedwith the updated API call.WHAT is this pull request doing?
Replaces a fragile process of guessing the meaning of an HTTP status code with making an explicit call to the Admin API to determine whether or not a storefront is password protected.
How to test your changes?
gg-query-password-settingand runpnpm install && pnpm run buildshopify theme dev --path <local theme path>shopify theme dev --path <local theme path>Checklist