There is nothing in the module that generates a JWT with this claim. Usually you'd have another application or some custom code generating the JWT based on access to a shared key.
Seems like this needs to be clarified in the docs?
pwolanin → created an issue.
pwolanin → created an issue.
pwolanin → created an issue.
pwolanin → created an issue.
pwolanin → created an issue.
pwolanin → created an issue.
pwolanin → created an issue.
patch #61 is failing for my colleague when filtering with jsonapi on the value of a referenced entity referenced by the main entity.
It's writing the WHERE clause such that it's filtering the main entity to the node ID of the referenced entity.
example:
- main entity house.
- house references a city node
- city references a state node
if I filter houses in jsonapi by state, the SQL where clause is filtering the house node ID by the state node ID.
greggles → credited pwolanin → .
So the difference is the \stdClass is one case where dynamic properties are allowed. I don't think there is a way to typehint the #[AllowDynamicProperties] attribute, however.
https://php.watch/versions/8.2/dynamic-properties-deprecated
Added one line to the gitlab config file
pwolanin → created an issue.
Yes, this should work. JWT modules does not generally check if the user has a session - perhaps it should!
You have to generate the JWT and pick the expiration time. Beware than anyone with access to that link will be able to download the provate file until the JWT expires
this would go in 3.x at this point
forward ported to 3.x also
This seems more-or-less duplicate to this bug reported several years ago:
#3189827: Access denied with bearer token on oauth/debug when Jwt is installed →
For this level of change I think it will need to go in 3.x. 2.x is just being minimally maintained
This is an old issue but increasingly relevant. Since it could require changes (adding a Key ID to JWT) it would also be good to handle before making 3.x stable:
✨
Support multiple keys
Active
I pulled all the trivial test and style changes over (getting tests to run on Drupal 9 and 10) to 📌 Get 2.x tests running on both Drupal 9 and 10 Active
Looks like the test pass - not really anything important otherwise, so merging
pwolanin → created an issue.
I was playing around with the CI yesterday, sorry for the noise.
Yes, the goal is to get something ready for this branch soon.
Personally I want to at least get these 2 issues into the branch first:
marking as 3.x since this seems too big for 2.x at this point which is probably EOL with Drupal 10
Is this the module that you see conflicting? https://www.drupal.org/project/simple_oauth →
A further approach could be a setting in settings.php to change the default header (or default and fallback headers) that would come via \Drupal\Core\Site\Settings which we are already injecting into this class
Something like this - passes a quick check, and maybe the minimum size of each segment should be larger.
This patch would break all existing sites, so it is not acceptable.
Clearly we already support the 'JWT-Authorization' header.
Since Oauth2 may be using a JWT as the token, I'm not sure there is an easy way to make these compatible.
A partial fix could be to change the method \Drupal\jwt\Authentication\Provider\JwtAuth::getJwtFromRequest() and make the regex more specific to the pattern of a JWT so it would ignore some other kind of token being used by OAuth2
pwolanin → made their first commit to this issue’s fork.
teknorah → credited pwolanin → .
I added dieterholvoet as a maintainer with full acccess
Looks like I could do this - I am a maintainer, but don't technically have "administer maintainers" on there. however, I can do it via my security team role
pwolanin → created an issue.
@daffie - yes, we need to support a lot of authenticated users, but a web application may not behave like a social media site in terms of the kind of data you need to load and show. Still, for our uses we are very much pained by the slowness of loading (and even more) saving entity data en mass. So, entity/field API performance one of our biggest pain points. We also use custom SQL queries at points, so it's not trivial to drop mongoDB in.
More personally in response - it feels ever more intimidating to get involved in core issues and it seems like a lot of good ideas linger with years of discussion. As a (listed) subsystem maintainer I don't feel like I have any special authority or reason to stay involved. Perhaps the core strategy will help define some technical directions that will reduce circular discussions on issues and encourage involvement.
@catch - that sounds like a lot of thing that may not come to pass.
Also - if I'm building a data-oriented web app, I don't think I'd start from Drupal CMS, and I think there needs to still be consideration for all the use cases that want to start from a reasonably fully functional Drupal core.
So, at the very least this issue sounds premature until the Drupal CMS being stable with a good search_api recipe is implemented. At that point, it sounds like the only concern is around user confusion?
Took a look at the 11.x MR. Looks like a simple and sensible fix, so moving back to RTBC.
This seems like a bad idea to me. The functionality of this module seems pretty essential for Drupal core to have a minima feature set.
pwolanin → created an issue.
There are interesting ideas from symfony about what to support. Their style of key rotation doesn't seem great for us where values are likely in the database an prod rotation happens only on the live site.
pwolanin → created an issue.
There is another request for a container parameter. The goal here is just to make it work better for everyone by default in a simple way
@ro-no-lo sounds like you have more of a support request - maybe try Slack?
We are using the JWT path auth in production for accessing private files, so I assure you that it can work.
Not sure I follow. There are similar examples in core that don't have a mapping, and a couple that do
15-
16-views.field.moderation_state_field:
17: type: views.field.field
18- label: 'Moderation state field'
core/modules/comment/config/schema/comment.views.schema.yml
21- label: 'Comment bulk form'
22-
23-views.field.commented_entity:
24: type: views.field.field
25- label: 'Commented entity'
26-
merged, thanks!
pwolanin → made their first commit to this issue’s fork.
Doing a quick test - I am still getting the OOM with that hook removed. Will double check with the specific diff applied.
Not sure why it would be related? As I mentioned above this seems related to a change in the config schema in the 3x series and is being triggered by config translation code.
volkswagenchick → credited pwolanin → .
Node module is also responding to various changes in hooks (e.g. comment update) and calling node_reindex_node_search()
This feels like a similar case, so I think the approach in the MR is reasonable given the limitations of the system.
xjm → credited pwolanin → .
larowlan → credited pwolanin → .
@drumm could you point to the code involved in project module? Is there some way we could make it possible to pick the release "series" when I'm making a new release?
In the users_jwt module I disallow an expiry more than 24 hours in the future, so I think that would be a reasonable max here also (at least for the form).
I agree with berdir here - pretty much every contrib release is a minor release and the availability of patch releases is a nice to have but not even necessary for most cases.
It seem like a "series" of releases used to be based on an actual git branch?
If I want to have the behavior currently being forced here I'd expect to need to create 2.0.x, 2.1.x, etc branches for each minor.
The fact that I have to specifically flag the old minor as supported and have it show on the project page seems especially weird and terrible. I don't need it to be unsupported unless it has a security vuln, but I certainly don't want it to show as a suggested download.
merged to 2.x and will cherry-pick to 3.x
Please make a 3.x issue to remove the old methods.
thanks alexpott!
not sure why it shows some commits against MR 12 as well as 15
Moved to target 3.x
Good idea - I didn't see this existing issue and started on this in
[#427911]
Can you include the hashed session ID as part of the JWT payload? That can't be used alone to hijack a session, but I worry it's kind of an internal detail that isn't really exposed as part of the session API
Also - digging into this before, it's seemed hard to bootstrap the session code if there is not an expected cookie.
pwolanin → created an issue.