Add back a google verification for old access_token

[SebC99]

(#6849 )

[ghost]

	Warnings
:warning:	Please add a changelog entry for your changes.

Generated by :no_entry_sign: dangerJS

[codecov[bot]]

Codecov Report

Merging #6992 (b7430eb) into master (c8e822b) will decrease coverage by 0.03%. The diff coverage is 42.85%.

@@            Coverage Diff             @@
##           master    #6992      +/-   ##
==========================================
- Coverage   93.92%   93.89%   -0.04%     
==========================================
  Files         181      181              
  Lines       13267    13279      +12     
==========================================
+ Hits        12461    12468       +7     
- Misses        806      811       +5     

Impacted Files	Coverage Δ
src/Adapters/Auth/google.js	83.13% <42.85%> (-9.83%)	:arrow_down:
src/Adapters/Storage/Mongo/MongoStorageAdapter.js	93.02% <0.00%> (+0.65%)	:arrow_up:
src/ParseServerRESTController.js	98.50% <0.00%> (+1.49%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update c8e822b...b7430eb. Read the comment docs.

[dplewis]

@SebC99 Can you update from master for the CI? Is this still a draft? Looks good so far.

[SebC99]

@dplewis I have no ideas why it fails

[dplewis]

Does the failing test pass locally?

[SebC99]

@mtrezza do you have any idea how to make it passes the tests?

[mtrezza]

You are only referring to the coverage, right?

[SebC99]

I think it's the only ones failing yes, but I have no idea of new tests to add (I'm very very bad at writing tests...)

[mtrezza]

⚠️ Important change for merging PRs from Parse Server 5.0 onwards!

We are planning to release the first beta version of Parse Server 5.0 in October 2021.

If a PR contains a breaking change and is not merged before the beta release of Parse Server 5.0, it cannot be merged until the end of 2022. Instead it has to follow the Deprecation Policy and phase-in breaking changes to be merged during the course of 2022.

One of the most voiced community feedbacks was the demand for predictability in breaking changes to make it easy to upgrade Parse Server. We have made a first step towards this by introducing the Deprecation Policy in February 2021 that assists to phase-in breaking changes, giving developers time to adapt. We will follow-up with the introduction of Release Automation and a branch model that will allow breaking changes only with a new major release, scheduled for the beginning of each calendar year.

We understand that some PRs are a long time in the making and we very much appreciate your contribution. We want to make it easy for PRs that contain a breaking change and were created before the introduction of the Deprecation Policy. These PRs can be merged with a breaking change without being phased-in before the beta release of Parse Server 5.0. We are making this exception because we appreciate that this is a time of transition that requires additional effort from contributors to adapt. We encourage everyone to prepare their PRs until the end of September and account for review time and possible adaptions.

If a PR contains a breaking change and should be merged before the beta release, please mention @parse-community/server-maintenance and we will coordinate with you to merge the PR.

Thanks for your contribution and support during this transition to Parse Server release automation!

[SebC99]

@parse-community/server-maintenance I think this one should be merged :)

[mtrezza]

Yes, I agree. Can you rebase this on master please and add a changelog entry? And is this a breaking change?

[sadortun]

@SebC99 @mtrezza Still interested in merging this ?

If so, can it be added to 5.4.x ? Or you prefer alpha ?

[mtrezza]

Sure, we could add this to alpha.

It seems that @SebC99 didn't allow this PR to be edited. Either they rebase it or you could open a new PR to get this ready for merge.

[sadortun]

@mtrezza

I was giving this a 2nd thought, and i think we should split this into google.js and googleAccessToken.js

I am not sure giving the unsecure client the option between providing either an id token or an access token is great.

I'm not knowledgeable enough in oauth2 to know if this should be enforced by the backend (via 2 auth adapters) or if a single auth adapter as suggested in this PR is a good idea.

It would be a simpler implementation to have two adapters each validating their own token. I dont think they should be used interchangeably.