While interceptors may be a solution, I already have code that have cross-context access and uses Named/Indexed access checker (at some part it mimic browser cross-origin policy), so having data property to migrate from deprecated checkers to newer one is mandatory for me. And if no data passed to callback, what is the purpose of that data parameter in SetAccessCheckCallback()?
On Tuesday, February 2, 2016 at 3:07:02 PM UTC+2, Jochen Eisinger wrote: > > Blink was merged into chromium a while ago, so there is no separate repo. > > As Toon points out, access checks will only trigger on cross-context > accesses, and probably not work for the code snippet you posted. > > Maybe your use case can be modelled using regular interceptors? > > best > -jochen > > On Tue, Feb 2, 2016 at 11:41 AM Toon Verwaest <[email protected] > <javascript:>> wrote: > >> Access checks only have meaning in a setting with multiple contexts from >> multiple origins. Unlike the other callback mechanisms, it's unlikely >> you'll want to use this mechanism in a non-browser setting. >> >> Regards, >> Toon >> >> On Tue, Feb 2, 2016, 11:28 <[email protected] <javascript:>> wrote: >> >>> Maybe I cloned wrong blink repo ( >>> https://chromium.googlesource.com/chromium/blink)? Just noted that >>> latest changes there is 4 month old. >>> >>> I writ php binding to v8 API (don't be confused with v8js), so my >>> typical use case for data in callbacks (or {Function,Property}CallbackInfo >>> obj) is to pass actual php function (specified in PHP runtime in userland) >>> that will be executed. >>> >>> meta-code is (use AccessCheckCallback to demonstrate the idea): >>> >>> v8::Local<v8::External> data; >>> v8::AccessCheckCallback callback = nullptr; >>> >>> if (php_callback) { >>> data = v8::External::New(isolate, to_callbacks_bucket(0, >>> php_callback)); >>> callback = php_v8_callback_access_check; >>> } >>> >>> v8::Local<v8::ObjectTemplate> template = >>> php_v8_object_template_get_local(isolate, php_v8_object_template); >>> >>> local_template->SetAccessCheckCallback(callback, data); >>> >>> // >>> bool php_v8_callback_access_check(v8::Local<v8::Context> >>> accessing_context, v8::Local<v8::Object> accessed_object/*, >>> v8::Local<v8::Value> data*/) { >>> bool security_retval = false; >>> zval retval; >>> zval args; // = [to_php_internal_repr(accessing_context), >>> to_php_internal_repr(accessed_object)]; >>> >>> php_v8_callback_call_from_bucket_with_zargs(0/*, data*/, &args, & >>> retval); >>> >>> if (Z_TYPE(retval) == IS_TRUE) { >>> security_retval = true; >>> } >>> >>> return security_retval; >>> } >>> >>> void php_v8_callback_call_from_bucket_with_zargs(size_t index, v8::Local >>> <v8::Value> data, zval *args, zval *retval) { >>> php_v8_callbacks_bucket_t *bucket; >>> >>> if (data.IsEmpty() || !data->IsExternal()) { >>> PHP_V8_THROW_EXCEPTION("Callback has no stored callback >>> function"); >>> return; >>> } >>> >>> bucket = static_cast<php_v8_callbacks_bucket_t *>(v8::Local<v8:: >>> External>::Cast(data)->Value()); >>> assert(bucket->size > index); >>> //... >>> } >>> >>> I use similar approach for all callbacks in v8 like (incl. now >>> deprecated NamedSecurityCallback and IndexedSecurityCallback) or Data() >>> accessor on PropertyCallbackInfo, FunctionCallback and others like >>> these. >>> >>> >>> On Tuesday, February 2, 2016 at 11:56:51 AM UTC+2, Jochen Eisinger wrote: >>> >>>> I'll do something similar. >>>> >>>> Note that blink already uses the new API, but it doesn't need data in >>>> the callbacks - just in the failed access check callbacks. >>>> >>>> May I ask what you're using the callbacks for? they're pretty much >>>> custom made for the use case in blink, so chances are they don't do what >>>> you think they do :-/ >>>> >>>> On Tue, Feb 2, 2016 at 9:58 AM <[email protected]> wrote: >>>> >>>>> Thanks for quick reply. >>>>> >>>>> Can you then apply patch above, please? >>>>> >>>>> Missed data looks definitely like a minor mistake during moving to new >>>>> SetAccessCheckCallback >>>>> (here you fix some of data >>>>> https://github.com/v8/v8/commit/e2675937d5b6d2e555edeaabcda7ce70551ea236 >>>>> ). >>>>> I checked blink code and if one decides to move to >>>>> SetAccessCheckCallback there, passing data to callback is a must. >>>>> >>>>> >>>>> On Tuesday, February 2, 2016 at 10:36:58 AM UTC+2, Jochen Eisinger >>>>> wrote: >>>>>> >>>>>> afaik there was no reason to drop data from the callback other that >>>>>> we didn't know of anybody using it. >>>>>> >>>>> >>>>> >>>>> >>>>>> I guess it's fine to add it back. >>>>>> >>>>>> On Mon, Feb 1, 2016 at 10:44 PM <[email protected]> wrote: >>>>>> >>>>> I guess something like this may allow data passing to callback: >>>>>>> >>>>>>> diff --git a/include/v8.h b/include/v8.h >>>>>>> index 171623a..afeb043 100644 >>>>>>> --- a/include/v8.h >>>>>>> +++ b/include/v8.h >>>>>>> @@ -4322,7 +4322,8 @@ enum AccessType { >>>>>>> * object. >>>>>>> */ >>>>>>> >>>>>>> typedef bool (*AccessCheckCallback)(Local<Context> >>>>>>> accessing_context, >>>>>>> - Local<Object> accessed_object); >>>>>>> + Local<Object> accessed_object, >>>>>>> + Local<Value> data = >>>>>>> Local<Value>()); >>>>>>> >>>>>>> >>>>>>> /** >>>>>>> diff --git a/src/isolate.cc b/src/isolate.cc >>>>>>> index 40d4c9f..2d15420 100644 >>>>>>> --- a/src/isolate.cc >>>>>>> +++ b/src/isolate.cc >>>>>>> @@ -843,7 +843,8 @@ bool Isolate::MayAccess(Handle<Context> >>>>>>> accessing_context, >>>>>>> VMState<EXTERNAL> state(this); >>>>>>> if (callback) { >>>>>>> return callback(v8::Utils::ToLocal(accessing_context), >>>>>>> - v8::Utils::ToLocal(receiver)); >>>>>>> + v8::Utils::ToLocal(receiver), >>>>>>> + v8::Utils::ToLocal(data)); >>>>>>> } >>>>>>> Handle<Object> key = factory()->undefined_value(); >>>>>>> return named_callback(v8::Utils::ToLocal(receiver), v8::Utils:: >>>>>>> ToLocal(key), >>>>>>> >>>>>>> >>>>>>> didn't tried it yet, but is idea correct or there was some other >>>>>>> reason to drop data? >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> v8-dev mailing list >>>>>>> >>>>>> [email protected] >>>>>> >>>>>> >>>>>>> http://groups.google.com/group/v8-dev >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "v8-dev" group. >>>>>>> >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>> >>>>>> >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> -- >>>>> -- >>>>> v8-dev mailing list >>>>> [email protected] >>>>> http://groups.google.com/group/v8-dev >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "v8-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> -- >>> v8-dev mailing list >>> [email protected] <javascript:> >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected] <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> -- >> v8-dev mailing list >> [email protected] <javascript:> >> http://groups.google.com/group/v8-dev >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
