-
Notifications
You must be signed in to change notification settings - Fork 2.8k
add jwt analyzer on console (close #1369) #1770
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
Conversation
|
Review app for commit da8687c deployed to Heroku: https://hge-ci-pull-1770.herokuapp.com |
|
Review app for commit 3975dda deployed to Heroku: https://hge-ci-pull-1770.herokuapp.com |
|
Review app for commit 0401074 deployed to Heroku: https://hge-ci-pull-1770.herokuapp.com |
|
|
||
| import jwt from 'jsonwebtoken'; | ||
|
|
||
| import Modal from 'react-bootstrap/lib/Modal'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let us implement a common modal at the root at the app that subscribes to title, content and isOpen in redux. Then we can change these properties from anywhere and the modal becomes reusable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey I am not able to wrap my head around this pattern where CommonModal can be used as
this.props.dispatch({ type: COMMON_MODAL_OPEN, title: <react-element>, content: <react-element>})
instead of
<CommonModal title={ title }>
<Body>
</CommonModal>
The body can be as complicated as it can. @wawhal Let me know what you think.
wawhal
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks fine.
We can make the reusable moddal and we're good to go.
|
Review app for commit 0aa6b52 deployed to Heroku: https://hge-ci-pull-1770.herokuapp.com |
|
I think it would be important to highlight a few things in the JWT analyser to make this useful:
Without these 2 things this is not useful. Also, the |
|
Deploy preview for hasura-docs ready! Built with commit af93aea |
|
Review app for commit 7a98d0a deployed to Heroku: https://hge-ci-pull-1770.herokuapp.com |
|
It is possible for me to achieve both. But not in a straight forward way. I have mentioned them below.
I will make
I can parse the payload to find out The above issues will become straight forward if for 1, the server hydrates a flag |
|
Why can’t the server template the entire jwt config for the console? That way you have everything. |
|
I think the problem is with the authentication. Server will not know
whether the user is authenticated or not on page load before the user is
asked to login.
The jwt stuff should be there in env only for authenticated requests.
@wawhal thoughts?
…On Wed, 20 Mar 2019 at 9:51 PM, Tanmai Gopal ***@***.***> wrote:
Why can’t the server template the entire jwt config for the console?
That way you have everything.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1770 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AX7uzCtQwfg44l1rwhaQtqezeRhUKYSzks5vYmAZgaJpZM4bzamR>
.
|
|
The server can template `is_jwt_set` and `claims_namespace`. Console does
not need the exact key anyway.
On Wed, Mar 20, 2019 at 10:17 PM Karthik Venkateswaran <
notifications@github.com> wrote:
… I think the problem is with the authentication. Server will not know
whether the user is authenticated or not on page load before the user is
asked to login.
The jwt stuff should be there in env only for authenticated requests.
@wawhal thoughts?
On Wed, 20 Mar 2019 at 9:51 PM, Tanmai Gopal ***@***.***>
wrote:
> Why can’t the server template the entire jwt config for the console?
>
> That way you have everything.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <
#1770 (comment)
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AX7uzCtQwfg44l1rwhaQtqezeRhUKYSzks5vYmAZgaJpZM4bzamR
>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1770 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAlnwyq6s5qYoOHlTBan1B_g_M1_SdZiks5vYmYrgaJpZM4bzamR>
.
|
|
But having key is good so that console can tell you if the jwt is valid per
Hasura. Otherwise capturing feedback about invalid jwt key only happens via
logs :(
…On Wed, Mar 20, 2019 at 2:17 PM, Anon Ray ***@***.***> wrote:
The server can template `is_jwt_set` and `claims_namespace`. Console does
not need the exact key anyway.
On Wed, Mar 20, 2019 at 10:17 PM Karthik Venkateswaran <
***@***.***> wrote:
> I think the problem is with the authentication. Server will not know
> whether the user is authenticated or not on page load before the user is
> asked to login.
>
> The jwt stuff should be there in env only for authenticated requests.
>
> @wawhal thoughts?
>
> On Wed, 20 Mar 2019 at 9:51 PM, Tanmai Gopal ***@***.***>
> wrote:
>
> > Why can’t the server template the entire jwt config for the console?
> >
> > That way you have everything.
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub
> > <
>
#1770 (comment)
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/AX7uzCtQwfg44l1rwhaQtqezeRhUKYSzks5vYmAZgaJpZM4bzamR
> >
> > .
> >
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <
#1770 (comment)
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AAlnwyq6s5qYoOHlTBan1B_g_M1_SdZiks5vYmYrgaJpZM4bzamR
>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1770 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIAWI-uK0oj0F80cB4zBMGQY2DJGs47ks5vYnsxgaJpZM4bzamR>
.
|
For invalid jwt, the response from server has But in any case, the key can't be templated on the console html, because then anyone can grab the jwt secret. Server can provide a separate admin only endpoint to dump the config. Does that make sense @coco98 ? |
|
According to the latest discussion with @dsandip and @rikinsk we are doing the following: Server
Console
Please add if I missed anything. |
|
Review app for commit 731ef1b deployed to Heroku: https://hge-ci-pull-1770.herokuapp.com |
|
Review app for commit bdf228c deployed to Heroku: https://hge-ci-pull-1770.herokuapp.com |
|
Review app for commit 952003c deployed to Heroku: https://hge-ci-pull-1770.herokuapp.com |
|
Review app for commit af93aea deployed to Heroku: https://hge-ci-pull-1770.herokuapp.com |
|
closed in favour of #1925 |
|
Review app https://hge-ci-pull-1770.herokuapp.com is deleted |
… expression types (#1770) <!-- The PR description should answer 2 important questions: --> ### What Introduces stricter validation for scalar boolean expression operators during the build process. This change helps catch invalid operator usage early by validating: - List type requirements for `_in` operator - Type matching for comparison operators (`_eq`, `_lt`, `_lte`, `_gt`, `_gte`) - Operator existence in data connector - Argument type compatibility with NDC operator types - Operators like `contains`, `icontains`, `starts_with` and `ends_with` etc. must be applicable to string scalar and argument type must be a string. These validations are controlled by a compatibility flag, issuing warnings for existing projects while enforcing strict errors for new projects created after or with a compatibility date set beyond the release date of this fix. ### How - Added new compatibility flag `ValidateScalarBooleanExpressionOperators` - Implemented validation checks in the build process to verify operator usage - Updated changelog with the new validations - Fix existing tests' metadata to avoid new warnings <!-- How is it trying to accomplish it (what are the implementation steps)? --> V3_GIT_ORIGIN_REV_ID: d468a6794af68d06a4a8fae3f8f1023c7824bdfb
Fix #1369
Description
JWT header as below can be analyzed

Affected components
Related Issues
close #1369
Solution and Design
Steps to test and verify
Create a jwt token and add a header
Authorization: Bearer <tokenin the explorer and click on the+icon to analyze.Limitations, known bugs & workarounds