grasmash → created an issue.
grasmash → created an issue.
Yes I did run updb and it did execute that function.
There might be a bug related to the configuration and how it's saved vs how it's used. I was getting some errors on cron, and needed to make this change to the config that was exported after saving settings in simple oauth. But these changes are unmade when re-saving the form.
diff --git a/config/default/simple_oauth.settings.yml b/config/default/simple_oauth.settings.yml
index 03d6b08ab..44a5defba 100644
--- a/config/default/simple_oauth.settings.yml
+++ b/config/default/simple_oauth.settings.yml
@@ -3,11 +3,7 @@ _core:
scope_provider: dynamic
token_cron_batch_size: 0
invalidate_tokens:
- consumer_update: consumer_update
- user_update: '0'
- user_password_change: '0'
- user_blocked: '0'
- user_roles_change: '0'
+ - consumer_update
public_key: ../keys/public.key
private_key: ../keys/private.key
disable_openid_connect: trueThe new MR works wonderfully for me! I visited /admin/config/people/simple_oauth, set it so that tokens won't invalidate on user save, and validated that saving the user does not invalidate the token.
grasmash → created an issue.
grasmash → created an issue.
grasmash → created an issue.
grasmash → created an issue.
Same. Patch is good.
nicxvan → credited grasmash → .
grasmash → created an issue.
grasmash → created an issue.
Added to the project page.
Adding mention of the JSON:API User Resources module as an alternative to REST for API-based user registration.
If you are interested in using JSON:API for user registration, see JSON:API User Resources → . It provides endpoints for registration, resetting password, and updating password.
And, if you want to change the email address or password for the user, you need to make a request like this. Current password is required for changing either mail or password.
curl --location --request PATCH 'https://www.example.com/jsonapi/user/user/1876ac28-5163-4ada-9ab7-481f60e6ed34' \
--header 'Content-Type: application/vnd.api+json' \
--header 'Accept: application/vnd.api+json' \
--header 'Authorization: Bearer [token]' \
--data-raw '{
"data": {
"type": "user--user",
"id": "1876ac28-5163-4ada-9ab7-481f60e6ed34",
"attributes": {
"name": "test 1234",
"mail": "test@example.com",
"pass": { "existing": "test", "value": "test1" }
}
}
}'
For user registration:
curl --location 'https://www.example.com/jsonapi/user/register' \
--header 'Content-Type: application/vnd.api+json' \
--header 'Accept: application/vnd.api+json' \
--data-raw '{
"data": {
"type": "user--user",
"attributes": {
"name": "test 123",
"mail": "test@test123456.com",
"pass": "test"
}
}
}'brianperry → credited grasmash → .
grasmash → created an issue.
alexpott → credited grasmash → .
@gorkagr I found the same thing. Breaks file field paths.
gábor hojtsy → credited grasmash → .
This would certainly have saved me hours of debugging. Perhaps this is a bridge too far, but it would also help to identify which modules are adding which tags/contexts.
Yes. Very confusing.
@lawxen sure! Maybe then I can look at supporting Social Auth 4.x.
I also did not find this response useful -- I needed an access token to be returned via simple oauth. Here's an implementation that I wrote for apple, but it could easily be used for google: https://www.drupal.org/sandbox/madmatter23/3474736 →
I needed a solution for this that would provide a simple oauth access key. Posting in case you're interested:
I've uploaded my solution to a sandbox in case anyone finds it useful https://www.drupal.org/sandbox/madmatter23/3474736 →
Unfortunately my implementation relies on social_auth_decoupled, which requires Social Auth 3.x and so I'm submitting an MR to the 1.x branch of social_auth_apple.
grasmash → changed the visibility of the branch 3212202-2x-decoupled to hidden.
I've put together a solution for this, which I can share. It's likely not the right architecture for contribution because it's not perfectly modular -- both google and apple social auth support are in the same module.
To make it work, we need to add a simple alter hook to social_auth_decoupled that allows us to modify the league settings when an SSO request is coming from an app -- the app will require a different client id.
grasmash → changed the visibility of the branch 3212202-decoupled to hidden.
grasmash → made their first commit to this issue’s fork.
Sorry I didn't realize that I needed to post something. What do you need from me? I'm still ready :)
I found a workaround for this that is good enough for my own needs. Basically, you need to user alter hooks to add cachebility metadata at the entity level. In my case, I wanted to add a max-age to a node when it had a file field with a presigned url that was set to expire.
This could be simplified. I had two different fields I had to take into account. Posting for posterity:
/**
* Implements hook_node_load().
*/
function mymodule_node_load($entities) {
$map = [
// node-type => s3 key.
'song' => [
's3_key' => 'songs',
// We only override the max-age if one of the file fields in actually populated.
'required_fields' => ['field_song_audio', 'field_song_archive'],
],
'firmware_release' => [
's3_key' => 'firmware-releases',
'required_fields' => ['field_firmware_archive'],
]
];
foreach ($entities as $entity) {
if ($entity->getEntityTypeId() == 'node' && in_array($entity->getType(), array_keys($map))) {
if (!shouldOverrideCacheHeaders($map, $entity)) {
continue;
}
$config = \Drupal::config('s3fs.settings');
if ($config->get('presigned_urls')) {
$presigned_urls = getPresignedUrls($config->get('presigned_urls'));
$s3_key = $map[$entity->getType()]['s3_key'];
foreach ($presigned_urls as $blob => $timeout) {
if (preg_match("^$blob^", $s3_key)) {
$cachebility_metadata = new CacheableMetadata();
$cachebility_metadata->setCacheMaxAge((int) $timeout);
$entity->addCacheableDependency($cachebility_metadata);
break;
}
}
}
}
}
}
/**
* @param $map
* @param $entity
*
* @return bool
*/
function shouldOverrideCacheHeaders($map, $entity): bool {
foreach ($map[$entity->getType()]['required_fields'] as $field_name) {
if (!$entity->{$field_name}->isEmpty()) {
return TRUE;
}
}
return FALSE;
}
/**
* @param string $presigned_urls_config
*
* @return array
* @see \Drupal\s3fs\StreamWrapper\S3fsStream->__construct())
*/
function getPresignedUrls(string $presigned_urls_config): array {
$presigned_urls = [];
foreach (explode(PHP_EOL, $presigned_urls_config) as $line) {
$blob = trim($line);
if ($blob) {
if (preg_match('/(.*)\|(.*)/', $blob, $matches)) {
$blob = $matches[2];
$timeout = $matches[1];
$presigned_urls[$blob] = $timeout;
}
else {
$presigned_urls[$blob] = 60;
}
}
}
return $presigned_urls;
}
@kingdutch it doesn't look like your patch actually addresses this issue. can you provide an example of how we can use the changes in your patch to achieve the goal of this issue, which is to NOT revoke users' access token when their account is updated, unless their password is changed?
Unfortunately https://git.drupalcode.org/project/simple_oauth/-/merge_requests/99.diff applies but does not appear to work.
can you leverage this? https://www.drupal.org/project/cache_control_override →
Is there a workaround or patch that would work on 6.0.x now?
Yes! Is there any way to achieve this in the meantime? I’m interested in making authenticated requests to a Drupal site to non-JSON API endpoints with various methods.
Got bit by this too. Which patch is best to use now?
For resetting password, POST a request to /jsonapi/user/password/reset with either a mail or name property in the body.
Moving from stripe_subscription issue queue. Requesting ownership of this module which appears to be abandoned. Requested on 28 Jan 2021, but there has been no response yet.
Bumping this again, can I please be granted maintainership to release a new version?
Fix rolled into issue fork here https://www.drupal.org/project/jsonapi_flag/issues/3463239 📌 Meta Issue: Fix all outstanding issues, upgrade to D10 Needs review
Looks like this was fixed upstream.
Fix rolled into issue fork here https://www.drupal.org/project/jsonapi_flag/issues/3463239 📌 Meta Issue: Fix all outstanding issues, upgrade to D10 Needs review
Fix rolled into issue fork here https://www.drupal.org/project/jsonapi_flag/issues/3463239 📌 Meta Issue: Fix all outstanding issues, upgrade to D10 Needs review
Fix rolled into issue fork here https://www.drupal.org/project/jsonapi_flag/issues/3463239 📌 Meta Issue: Fix all outstanding issues, upgrade to D10 Needs review
grasmash → created an issue.
grasmash → created an issue.
Based on some more review, it's more accurate to say that a user has both the authenticated and premium roles, not that premium inherits from authenticated. Therefore, the solution would be to grant the authenticated role to the token as well as the premium role.
grasmash → created an issue.
nicxvan → credited grasmash → .
nicxvan → credited grasmash → .
nicxvan → credited grasmash → .
If I had to guess I'd say this broke it:
https://git.drupalcode.org/project/mailchimp/-/compare/2.2.2...2.2.3?fro...
The code seems to assume that if "allow_unsubscribe" is not present and true, then there must be no subscription happening. That's not true. Subscription can be mandatory.
grasmash → created an issue.
grasmash → created an issue.
nicxvan → credited grasmash → .
I’m not currently a maintainer. Happy if someone else maintains it. Let me know if there’s someway I can help.
The performance post depends completely on the application. It should be much faster for applications that have large number of dependencies, because optimizing the auto loader reduces disk reads during autoloading.
This is the best practice recommended by composer itself for production applications. Also, don’t think there’s any downside to it. The only time that you should not optimize the auto loader is when you are working in a development environment, because the dynamic file discovery makes it easier during development to create new files, change names, etc., without having to dump the auto loader each time you make a change.
See https://getcomposer.org/doc/articles/autoloader-optimization.md#:~:text=....
grasmash → created an issue.
This happens because for some reason, _unwanted_email_registration_filter_email() is called twice. The first time $email is properly populated, the second time it is NULL.
PHP 8.2, Drupal 10.2.3.
grasmash → created an issue.
grasmash → created an issue.
grasmash → created an issue.
I don't understand how this can be achieved in 6.0. The goal is to dynamically assign scopes based on the user role. The ability to add default roles per consumer does not achieve assigning default roles per user -- users of different roles may use the same consumer.
Related changes were made here: https://www.drupal.org/project/achievements/issues/3182487 🐛 Form fails on drupal 9 because of non-existing method Fixed
Is this still an issue?
Doesn't this need an update hook for existing achievement entities?