PDA

View Full Version : مشتق کردن کلاس نگه دارنده دیتاهای Event از کلاس EventArgs اجباری است ؟



hakan648
شنبه 20 خرداد 1391, 23:30 عصر
سلام

If you don’t find an existing event data class that can hold your event data, you’ll need to implement
your own custom event data class that derives from EventArgs or one of its subclasses and exposes
properties that correspond to your event data.

سوال من در مورد متنی که در بالا نوشته شده هست .
یعنی حتما باید کلاس Eventargs ما از کلاس EventArgs مشتق شده باشه ؟ ( منظورم کلاسی هست که بوسیله اون ، دیتاهای ایونت رو به متد مربوطه پاس میدیم هست )

یک کلاسی نوشتم که از این کلاس مشتق نشده بود و مشکلی هم نداشت .

لطفا راهنمایی بفرمایید که چرا در این کتاب ، مشتق شدن از کلاس EventArgs اجباری هست !؟

البته این کتاب برای dotNet2 نوشته شده - امکان داره که در 4 این اجبار از بین رفته باشه ؟

با تشکر

tooraj_azizi_1035
یک شنبه 21 خرداد 1391, 14:38 عصر
سلام


ببین علت رو می تونی از این متن بفهمی:

There actually is a good reason for requiring the second argument to derive from EventArgs if your fully-trusted code hosts third-party code as partially-trusted.
Because the callback to the event handling delegate is done in the context of the raising code and not the third party code, it is possible for malicious third-party code to add a privileged system operation as an event handler and thus potentially execute an escalation of privilege attack by running code in your fully-trusted context that their partially-trusted context could not run.
For example, if you declare a handler as type int -> void then the third-party code could enqueue YourEvent += Enviroment.Exit(-1) and have you exit the process unintentionally. This would obviously cause an easy-to-detect problem, but there are far more malicious APIs that could be enqueued to do other things.
When the signature is (object, EventArgs) -> void then there are no privileged operations in the framework that can be enqueued because none of them are compatible with this signature. It's part of the security code review in the framework to ensure this (unfortunately I cannot find the source where I read this).
So in certain circumstances there are valid security concerns as to why you should use the standard pattern. If you're 100% sure your code will never be used in these circumstances then the event signature guideline isn't as important (apart from other developers thinking WTF), but if it might be then you should follow it.