Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PWA-3154:GraphQL cacheable requests always have Authorization Bearer … #4240

Merged
merged 6 commits into from
Apr 1, 2024

Conversation

glo11372
Copy link
Collaborator

@glo11372 glo11372 commented Mar 7, 2024

Description

GraphQL cacheable requests always have "Authorization Bearer" header
Steps to test the behaviour :

1- sign up.in Venia.magento.com or any PWA store
2- login
3- check network tab on any page and search for GraphQL requests which should be cached such as CMSPages
4- check the request header you will not find Authorization Bearer header exist
5- Varnish will cache that request's response.

Related Issue

Closes # https://jira.corp.adobe.com/browse/PWA-3154

Acceptance

Verification Stakeholders

Specification

Verification Steps

Test scenario(s) for direct fix/feature

Test scenario(s) for any existing impacted features/areas

Test scenario(s) for any Magento Backend Supported Configurations

Is Browser/Device testing needed?

Any ad-hoc/edge case scenarios that need to be considered?

Screenshots / Screen Captures (if appropriate)

Breaking Changes (if any)

Checklist

  • I have added tests to cover my changes, if necessary.
  • I have added translations for new strings, if necessary.
  • I have updated the documentation accordingly, if necessary.

@glo11372 glo11372 added pkg:peregrine version: Minor This changeset includes functionality added in a backwards compatible manner. labels Mar 7, 2024
@glo11372 glo11372 requested a review from glo82145 March 7, 2024 09:23
@pwa-studio-bot
Copy link
Collaborator

pwa-studio-bot commented Mar 7, 2024

Messages
📖

Associated JIRA tickets: PWA-3154.

📖 DangerCI Failures related to missing labels/description/linked issues/etc will persist until the next push or next pr-test build run (assuming they are fixed).
📖

Access a deployed version of this PR here. Make sure to wait for the "pwa-pull-request-deploy" job to complete.

Generated by 🚫 dangerJS against cc928d5

__esModule: true,
default: jest.fn(() => 'auth')
}));
// jest.mock('@magento/peregrine/lib/Apollo/links/authLink', () => ({
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please donot comment line like these .. remove it from code

@@ -1,6 +1,6 @@
import { createHttpLink } from '@apollo/client';

import createAuthLink from '@magento/peregrine/lib/Apollo/links/authLink';
// import createAuthLink from '@magento/peregrine/lib/Apollo/links/authLink';
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove code

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

glo82145
glo82145 previously approved these changes Mar 18, 2024
@fooman
Copy link
Contributor

fooman commented Mar 25, 2024

How will signed in customer functionality work with the authLink removed?

authorization: token ? `Bearer ${token}` : ''

@glo85315
Copy link
Collaborator

glo85315 commented Mar 28, 2024

How will signed in customer functionality work with the authLink removed?

authorization: token ? `Bearer ${token}` : ''

Screenshot 2024-03-27 at 6 27 201PM
Hi this will work after removing authLink .because when user logined server will create cookies and send back to client side. in client side cookies will store in user browser and this cookies will take in to next subsequent API Header request as cookies. then server validate cookie and if its valid it will allow the authetication.

please see attached screen shot .red mark

  • Authentication: When a user logs in to your application, your server typically creates a session for that user and issues a session identifier in the form of a cookie. This cookie is then stored in the user's browser.
  •   Subsequent Requests: When the user performs actions or accesses protected resources that require authorization, your React application sends requests to the server. The browser automatically includes the cookies associated with the domain in the request headers.
    
  •   Server-side Authentication: On the server side, your application checks for the presence of the session cookie in the request headers. If the session cookie is present and valid, the server identifies the user associated with the session and authorizes the request accordingly.
    

@glo82145
Copy link
Collaborator

glo82145 commented Apr 1, 2024

deploy pr-test

@glo82145
Copy link
Collaborator

glo82145 commented Apr 1, 2024

deploy pwa-pr-test

@glo82145 glo82145 merged commit d8f7e84 into develop Apr 1, 2024
7 checks passed
glo82145 added a commit that referenced this pull request Jun 5, 2024
#4240)

* PWA-3154:GraphQL cacheable requests always have Authorization Bearer header

* PWA-3154:Removing Commented lines

* Update index.spec.js.snap

* Update index.spec.js.snap

---------

Co-authored-by: Aanchal Pawar <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pkg:peregrine Progress: done version: Minor This changeset includes functionality added in a backwards compatible manner.
Projects
Development

Successfully merging this pull request may close these issues.

5 participants