I did digged deeper and want to clarify something. Our frontend is a Vue3 frontend on localhost:3000. The backend however was on a domain like foobar.local. That means, that Drupal had send the session cookie with the domain: ".foobar.local". Vite, the server while developing has forwarded that cookie to the browser via proxy. With that in mind, the Drupal session cookie was never accepted by the browser because of the different domains. After hours of research I found that Vite has settings that the proxy can rewrite the cookie domains to for example localhost. With that in place the logout works because the session cookie is accpeted and will be used in the logout process.
BUT for whatever reason it still does not work in staging or production environments were the Drupal session domain settings is set to ".foobar.com" and both frontend and backend are on different subdomains. No idea why, but there ist still a problem.
However, I still don't understand why a session cookie is important, IF a JWT cookie authenticates the user to drupal.
I hope I can correctly describe my problem with Postman images.
The question about the session cookie makes me curious. Why is that needed? Should it be not enough to send the JWT token as Bearer with any request? THe thing is the vue3 SPA Website works flawlessly in terms of requests ONLY the logout does not work.
If you follow the screenshots by timestamp you'll see why I get the
{
"message": "'csrf_token' URL query argument is invalid."
}
message.
Side note: I had "Sanitize filenames" everything off.
A fix will be to turn everything on there and reupload the images with spaces in it.
ro-no-lo → created an issue.
Workaround is to disable the Template Error Reporting.
ro-no-lo → created an issue.
ro-no-lo → created an issue.
ro-no-lo → created an issue.
Yeah I messed up here. I'll try to fix it.
I'll provide a fix for the 1.x branch, which will introduce a ignore list. I just have to figure out the git stuff, as always.
ro-no-lo → created an issue.
ro-no-lo → created an issue.
ro-no-lo → created an issue.
ro-no-lo → created an issue.
Okay, that's life. I debugged this issue for like 4 hours, but find the unsatisfying solution after posting it on drupal.org within 10 minutes.
For anybody run into the same thing: I do have the https://www.drupal.org/project/node_view_permissions → module installed, which I had setup that the current user could not VIEW the first type of entity (see above text). This seem to lead to the awkward problem, that the user can create an entity, but cannot reference it later, because he could not "see" this type of reference. Therefore if he can't see it he propably shall not reference it.
Don't like it, that I have to deal on a coding level with that. But that's what I found.
ro-no-lo → created an issue.
This seems to be an problem with inline forms module (or so).
I use Vue3 as a JS Frontend. I save the JWT in the local browser storage. For neat relogin on return. The classic Session Cookie is not present. The JWT Token is. Therefore I do have the JWT Token while logged in.
I have no idea if that answered your question. As auth, we use the BEARER on each request.
ro-no-lo → created an issue.
I checked: when jsonapi_image_styles is uninstalled it works as expected.
I digged a bit deeper.
The ImageStyleNormalizedFieldItemList::computeValue is called in the Validationphase of the FileUpload call, which I don't understand, because, what exactly are you validating there? No idea. Anyways and the same method is called in the serializition Phase, which makes more sense. The thing is even with stepping through the process, I do not understand why it fails, because jsonapi is supposed to anser an fileupload with a json string of the newly created file--file objects.
It bothers me even more, that the upload of the image and the attachment to the entity with the reference seem to work perfectly. Only an EarlyRendererWrapperSomething is bothered and throws an exception. :-(
I had this also. The thing is this: When I upload IMAGES: via the JSON:API process described here: https://www.drupal.org/node/3024331 → it seems that the jsonapi_image_style module creates a `CachableResponse`. which will throw an exception in the file:
File: EarlyRenderingControllerWrapperSubscriber.php
// If a non-Ajax Response or domain object is returned and it cares about
// attachments or cacheability, then throw an exception: early rendering
// is not permitted in that case. It is the developer's responsibility
// to not use early rendering.
elseif ($response instanceof AttachmentsInterface || $response instanceof CacheableResponseInterface || $response instanceof CacheableDependencyInterface) {
throw new \LogicException(sprintf('The controller result claims to be providing relevant cache metadata, but leaked metadata was detected. Ensure you are not rendering content too early. Returned object class: %s.', get_class($response)));
}
else {
// A Response or domain object is returned that does not care about
// attachments nor cacheability; for instance, a RedirectResponse. It is
// safe to discard any early rendering metadata.
}
}
As info: I have an entity where uploading any type of files is okay. When I upload a Image the error occurs and the CachableResponse has a content of:
{"jsonapi":{"version":"1.0","meta":{}},"data":[{"type":"file--file","id":"c4837397-5e48-41d6-9002-60f68d0e02f5","attributes":{"drupal_internal__fid":721,"langcode":"en","filename":"13.jpeg","uri":{"value":"private:\/\/2024-02\/13_1.jpeg","url":"\/system\/files\/2024-02\/13_1.jpeg?token=nOrLl1pNJflU-H2bVCtDthM6moemK64Q9MDQaN6PRCc×tamp=1708955605"},"filemime":"image\/jpeg","filesize":8020217,"status":true,"created":"2024-02-26T13:53:25+00:00","changed":"2024-02-26T13:53:25+00:00","image_style_uri":{"avatar":"http:\/\/foobar.local\/system\/files\/styles\/avatar\/private\/2024-02\/13_1.jpeg?token=Rt1fiI8d14VxngMdOnP9r745AXDBhH6VaTcFFckMzIs×tamp=1708955605&itok=LM9rqf7H","max_650x650":"http:\/\/foobar.local\/system\/files\/styles\/max_650x650\/private\/2024-02\/13_1.jpeg?token=tNO_kBMwcuLRAjt2I9pUX05glzRjdCmK88dC6QVKOhQ×tamp=1708955605&itok=QYcmOtOQ","thumbnail":"http:\/\/foobar.local\/system\/files\/styles\/thumbnail\/private\/2024-02\/13_1.jpeg?token=l4ViEWtsOLHCRn1G8b3v7NZGhBzZXoPwm_jfys1-OlY×tamp=1708955605&itok=Oypb40X-","usericon":"http:\/\/foobar.local\/system\/files\/styles\/usericon\/private\/2024-02\/13_1.jpeg?token=szA6cAFC67hB-vPw9zZMvdkhWiX5e4xRBW4DxajFJk0×tamp=1708955605&itok=SIMJP2lO"}},"relationships":{"uid":{"data":{"type":"user--user","id":"cfecacbc-701e-4bb6-83e3-2a8b15a83fbe","meta":{"drupal_internal__target_id":32}}}}}]}
At least for me, this happens. Uploading 1 or more PDF. No problem. Uploading JPGs: Exception.
As far as I know /user/logout is a POST call. Just saying.
ro-no-lo → created an issue.
With the latest PHP 8.x I think we could avoid many of these phpDocs by just using the types inside the method signature.
OMG I found a solution. Maybe it is helpful to someone. After Updating to Drupal 10, Drupal lost the *Reference Method* of the Entity. It told me that the selection handler is broken. It could also be, that the uninstall of WMBert as a WIDGET! was the cause. I don't know. Anyways, when I change it to default and pick the correct Entity (storage data) then everything works as expected. (See both screenshots)
Just as a note. If I remove the field from the entity and re-create it with the exact same data AND after that import via SQL the original data into the db. Everything works.
Which leads me to believe that something in the Drupal registry about the storage_data fields is messed up. But because it is Drupal I have no idea where that is and I cannot give advice what to do without deleting and recreating the same data. :-(
To reinterate: I made a Drupal 9 to 10 update prior to this problem.
I checked my other entities which reference to storage_data fields. And ALL have somewhat broken references.
It seems that something at some magic place went wrong, because when I create a second field which references to the same storage_data entities it works finde.
I now have to find a way to fix everything without loosing data.
Btw. no pending update db or entities updates are in queue. Everything is uptodate.
I guess you are right. I thought of a more fundamental design flaw in core. But I take it.
I have no idea why only me has this problem. But something is messed up and I expect the ValidReferenceConstraintValidator.php be part of the problem. I CAN create a storage_data entity, BUT I cannot reference it in another entity. The Validator messes up the valid_entity_ids with the invalid IDs and thus it complains all day long.
There seems to be a deeper problem involved here. Because after updating to D10 I cannot save even entities with referenced storage engine items anymore. It just complains. See screenshot.
ro-no-lo → created an issue.
Thanks @FMB it worked. I still have no idea, why we need this hook.
ro-no-lo → created an issue.
ro-no-lo → created an issue.
ro-no-lo → created an issue.
ro-no-lo → created an issue.
In my opinion. the correct patch should be
`(object $event, string $eventName = null): object`
ro-no-lo → created an issue.
ro-no-lo → created an issue. See original summary → .
Thank you. I'll try it.
ro-no-lo → created an issue.
ro-no-lo → created an issue.
ro-no-lo → created an issue.
For anybody comming here from Google, like me, you can achieve this with the jsonapi_extras module. There is config page "JSON:API Resource overrides" were you can choose to override settings. To do so you choose the entity and click the override button. Then choose the json_raw field of your liking and go to "Advanced" and pick the enhancer "JSON Field".
After that, at least for me, the result of an json_field in the JSON:API was pure JSON.
(I still have to test, if the POST and PATCH will handle the pure JSON as well, but ready pure JSON is a great start)
ro-no-lo → created an issue.
After a vendor/bin/drush cr the error goes away. At least for me.
ro-no-lo → created an issue.
ro-no-lo → created an issue.
Okay, I keept digging and got to the point were the stange condition is added. The TemporaryQueryGuard has a static method called getAccessConditionForKnownSubsets(...) which tests 3 things (if all other access checks were neutral or granted or so). a "published" subset, a "enabled" subset and an "owner" subset. If all 3 of these fail, than it adds the unsovable condition.
Well, as far as I can tell, the "published" check returns neutral the "enabled" is false and the "owner" check returns neutral as well, which leads to the unsolvable condition of profile_id < 1 AND profile_id > 1.
I have - at this point - no idea how I can solve that, to make it usable.
I added an image which shows the point were _somehow_ the applyAccessConditions() method of the TemporaryQueryGuard decides to add the unsolvable condition.
ro-no-lo → created an issue.
As a test I gave a non-administrator role of that example user (UUID 5) all profiles permissions and removed one by one to find the permission which might be the cause for the unexpected behavior.
When I remove the permission "Administer profiles" the JSON:API result (filter by uid.id) went empty array. But this is of cause problematic, because that permission is correctly labeled as "danger only give trusted users". All other non-administrative permission where still enabled.
This leads me to believe that some permission checks are wrong wired here.
ro-no-lo → created an issue.
Oh I see that you already did the work, but to be honest I am not *fit* enough to check if your solution will work in all circumstances. I hope the community can help here.
Hi,
thanks for your feedback. I do know that this solution is not optimal. As written in the project description, it was developed with the suggestion of one of the JSON:API core maintainers in mind. Feel free to find a better way.
Hi arti_parmar,
thanks for your time and effort to create the patch. I did it myself, because I noticed your .patch to late. I keeped a few long line warning, but the errors should be gone.
Hi, for everyone coming to this issue after 10+ years, I have created a small Token extension module, were aliased tokens can be used in a programmatically way. It is a different approach, in syntax, but if you are desperate you might give it a try.
https://www.drupal.org/project/token_aliases →
(You may have to use it from the git directly.)
Usage:
$token_service = \Drupal::service('token_aliases');
$string = 'Hello [user1:username], we have news from [user2:username] see [node:title] and [my_node:title] for more info.';
// Fully loaded User entities which are keys with the aliases used in the string.
$data = [
'user1' => $user1,
'user2' => $user2,
'node' => $node,
'my_node' => $my_node,
];
$result = $token_service->plainReplace($string, $data);
Hi,
I already updated the code to a version 3.x.x because it changed that much, but the Drupal gut system prevents me of signing in or something. It is really frustrating. I might try it again. It was something with a git repo token or so, which was not linking to the position were I can setup that. I do have one for another project here on drupal.org, but somehow the drupalgit is bossing me around for something it misses.
Sorry for that.
ro-no-lo → made their first commit to this issue’s fork.