Anti CSRF module for ASP.NET
راستشو بگم از مطلبی که گذاشتین خیلی سر درنیوردم.
الان در این کد:img src="http://www.example.com/logout.aspx">
چه اتفاقی میفته فرض کنید مدیر سیستم از این صفحه بازدید کنه.آیا برای SRC میشه کدهای جاوا نوشت که مثلا اطلاعات سشن رو میل بزنه؟آیا همچین دسترسی به سشن یا کوکی داریم؟
میشه یکمی هم از فرق روشهای Post و Get در این باره بگین؟من فرقشونو در این زمینه متوجه نشدم.
اگر میشه یکم بیشتر (جسارته اما با یه مثال عملی تر) مطلب رو باز کنین
موفق باشید
نیما
تعرفه مصوب سال 1390
گاهی از اوقات که ... چه عرض کنم، «عموما» آمار و اطلاعات ما از دره سیلیکون بیشتر است از آمار و اطلاعات داخلی؛ از آمار عطسه کردن مدیر اجرایی گوگل تا جیغ کشیدن رئیس مایکروسافت تا نوسانات فشار خون استیو جابز در یک ماه اخیر و تا ... عوض شدن لوگوی فلان موبایل!
به همین جهت برای «تنوع» شاید بد نباشد «تعرفه نرخ پایه خدمات فنی - تخصصی انفورماتیک برای سال 1390» منتشره توسط سازمان نظام صنفی رایانهای کشور را هم مطالعه کنیم:
سوال در مورد Authenticate_Request
در مقالهی قبلی وقتی نسخهی یک اسمبلی را مشخص میکردیم، از 4 عدد که با نقطه از هم جدا شده بودند، استفاه کردیم که در جدول زیر این 4 نامگذاری را مشاهده میکنید:
شماره بازبینی Revision Number | شماره ساخت Build Number | شماره جزئی Minor Number | شماره اصلی Major Number |
2 | 719 | 5 | 2 |
اسمبلی بالا به ورژن یا نسخهی 2.5.719.2 اشاره دارد که دو شمارهی اول (2.5) مثل تمامی برنامهها به میزان تغییرات کارکردی یک اسمبلی اشاره دارد و عموم مردم هم نسخه یک نرم افزار را به همین دو عدد میشناسند. عدد سوم به این اشاره دارد که در شرکت، این ورژن از اسمبلی چندبار build شده است و شما باید به ازای هر Build این عدد را افزایش دهید. عدد آخری به این اشاره دارد که در طول روز انتشار، این چندمین Build بوده است. اگر در زمان ارائهی این اسمبلی باگ مهمی در آن یافت شود، با هر بار Build آن در یک روز، باید این عدد افزایش یابد و برای روزهای آتی این مقدار مجددا آغاز میشود. مایکروسافت از این سیستم نسخه بندی استفاده میکند و بسیار توصیه میشود که توسعه دهندگان هم از این روش تبعیت کنند.
در جدول سابق شما متوجه شدید که سه نسخه بندی را میتوان روی یک اسمبلی اعمال کرد که به شرح زیر است:
AssemblyFileVersion: این شماره نسخه در منابع اطلاعاتی Win32 ذخیره میگردد و کاربرد آن تنها جهت نمایش این اطلاعات است و CLR هیچ گونه ارجاع یا استفادهای از آن ندارد. در حالت عادی، شما باید دو شماره اولی را جهت نمایش عمومی مشخص کنید. سپس با هر بار Build کردن، شمارههای ساخت و بازبینی را هم به همان ترتیب افزایش میدهید. حالت ایدهآل این است که ابزار AL یا CSC به طور خودکار با هر بار Build شدن، با توجه به زمان سیستم، به طور خودکار این دو شماره آخر را مشخص کنند ولی متاسفانه واقعیت این است که چنین کاری صورت نمیگیرد. این اعداد جهت نمایش و شناسایی اسمبلی برای اشکال زدایی مشکلات اسمبلی به کار میرود.
AssemblyInformationalVersion: این شماره نسخه هم در منابع اطلاعاتی Win32 ذخیره میگردد و تنها هدف اطلاعاتی دارد. مجددا اینکه CLR هیچ گونه اهمیتی به آن نمیدهد. این شماره نسخه به محصولی اشاره میکند که شامل این اسمبلی است.
به عنوان مثال ورژن 2 یک نرم افزار ممکن است شامل چند اسمبلی باشد که ورژن یکی از این اسمبلیها یک است و دلیلش هم این است که این اسمبلی از نسخهی 2 به بعد اضافه شده و در نسخهی یک نرم افزار وجود نداشته است. به همین دلیل در این مدل از نسخه بندی شما دو شماره اول را به نسخه خود نرم افزار مقداردهی کرده و سپس مابقی اعداد را با هر بار پکیج شدن کل نرم افزار با توجه به زمان افزایش میدهید.
AssemblyVersion: این شماره نسخه در جدول متادیتای AssemblyDef ذخیره میگردد. CLR از این شماره نسخه جهت اتصال نام قوی Strongly Named به اسمبلی استفاده میکند (این مورد در فصل سه کتاب توضیح داده شده است). این شماره نسخه بسیار مهم بوده و به عنوان شناسهی یکتا برای اسمبلی استفاده میشود.
موقعیکه شما شروع به توسعهی یک اسمبلی میکنید، باید هر 4 شماره نسخه را مقداردهی کرده و تا زمانیکه توسعهی نسخه بعدی آن اسمبلی را آغاز نکردهاید، نباید آن را تغییر دهید. علت اصلی آن این است که موقعیکه اسمبلی «الف» با یک نام قوی به اسمبلی «ب» ارجاع میکند، نسخهی اسمبلی «ب» در ورودی جدول AssemblyRef اسمبلی «الف» قرار گرفته است. این مورد باعث میشود زمانیکه CLR به بارگزاری اسمبلی «ب» احتیاج دارد، دقیقا میداند که چه نسخهای با اسمبلی «الف» ساخته و تست شده است . البته این احتمال وجود دارد که CLR نسخهای متفاوت از اسمبلی را با Binding Redirect بار کند که ادامهی این مباحث در فصل سوم دنبال میشود.
تعرفه مصوب سال 1390
در کل این نوع حرکات، جهت انتشار حداقل حقوق برنامه نویس یا مصرف کننده بسیار مفید است. خیلی از برنامه نویسها حداقل حقوق خودشون رو نمیدونند و بیجهت بازار رو خراب میکنند. عدهای سودجو هم هستند که برای مثال پروژههای سورس باز رو با یک لایه فارسی به قیمتهای گزافی میفروشند. روشن شدن یک سری از حداقلها در کل به نفع جامعه است.
اگر مدتها کارتان برنامه نویسی WinForms بوده و اکنون احساس کردهاید که دیگر WinForms آنچنان توسعه و بسط نخواهد یافت و اکنون WPF تبدیل به انتخاب اصلی شرکتهای بزرگ شده است و همچنین از پرسه زدن در فورومهای وارز جهت یافتن فلان کامپوننت خاص برای زیباسازی ظاهر برنامههای خود خسته شدهاید و نیاز به معادل بهتری که اساسا در جهت حذف این بازار سیاه تهیه شده است، احساس میکنید، بهترین گزینهی موجود WPF خواهد بود که با کمی دقت، میتوان پروژههای آنرا تبدیل به پروژههای وب نیز نمود. مطلب 54 صفحهای ذیل، خلاصهی کاربردی سریعی را جهت ارتقاء برنامه نویسهای WinForms به WPF ارائه میدهد:
ماخذ
آیا در کنفرانسهای توسعه دهندگان داخلی شرکت میکنید؟
خب فکر میکنم همین خودش دیگه برای شرکت نکردن در یک چنین کنفرانسی کفایت میکنه. وقتی که سطح دید و سواد اون کنفرانس در حد تولید وب سایت دانلود ! و یا اپلیکیشنهای کپی شده از نمونههای خارجی هست، دلیلی برای یک توسعه دهنده وجود نداره که اون رو به شرکت کردن وادار کنه.
در واقع اگر بخوام دقیقتر و رکتر توضیح بدم، این کنفرانسها بیشتر یک بازار بلیط فروشی (هر بلیط حدود ۲۰ تا ۵۰ هزار تومان) و تبلیغ کالاهای کپی شده هستن تا یک کنفرانس در رابطه با پیشرفت علم نرم افزار.
قابلیت جالبی در ویژوال استودیو وجود دارد که شاید کمتر در مورد آن مطلب نوشته شده است و آن هم تنظیم پروژه به نحوی است که اگر برای کلیه موارد public کامنتی نوشته نشود، برنامه کامپایل نخواهد شد. همچنین اگر نام پارامتری را تغییر دادید، اما کامنت مرتبط با آن را به روز نکردید، باز هم خطای کامپایل را دریافت خواهید کرد که از این لحاظ هم بسیار عالی است و به نوعی «وادار کردن خود به کامنت نوشتن» است.
برای این تنظیم، ابتدا به برگه خواص پروژه مراجعه کنید. سپس در قسمت Build تنظیمات زیر را اعمال نمائید:
Treat warnings as errors را بر روی All قرار دهید.
در ذیل آن، در قسمت Output، گزینهی XML Documentation file را تیک بزنید.
البته این تغییر بهتر است در یک پروژه جدید مد نظر باشد، چون اگر الان اقدام به این تنظیم کنید، به طور قطع از خیر آن خواهید گذشت! کامنت نویسی به مرور و در حین توسعه یک برنامه یا کتابخانه قابل تحمل است وگرنه اگر برای روز آخر قرار داده شود، به احتمال زیاد انجام نخواهد شد.
مطالب مرتبط:
برای شروع به نصب و پیکربندی، باید بدانیم به چه چیزهایی احتیاج داریم. قطعا به کتابخانه React نیاز داریم. اما بسته به نوع کدنویسی که میخواهیم در پیش بگیریم، احتمالا به کتابخانههای دیگری هم احتیاج پیدا خواهیم کرد. در قسمت قبل نحوهی ساخت یک تگ HTML، با React آورده شد. دوباره به آن نگاهی بیاندازیم:
var ClickableImage = function (props) { return ( <a href={props.href}> <img src={props.src} /> </a> ) };
React از دو روش برای ساخت تگها استفاده میکند. روش سادهتر همین مثالی است که در بالا آمده؛ یعنی از تگهای HTML را به صورت مستقیم استفاده میکند. روش دیگر، استفاده از زبان جاوااسکریپت به تنهایی است. مثلا تگهای <a> و <img> بالا به صورت زیر نوشته میشوند:
var ClickableImage = function(props) { React.createElement( "a", {href: props.href}, React.createElement( "img", {src: props.src} ) ) };
وقتی تصور کنیم که قرار است یک جدول یا یک فرم را ایجاد کنیم، ارزش روش سادهتر، مشخص میشود. در واقع تگهایی که استفاده شده، واقعا تگهای HTML نیستند؛ چیزی هستند به نام JSX.
JSX
JSX زبان یا روشی است که اجازه میدهد از تگهای مشابه با HTML در جاوااسکریپت استفاده کنیم. به دلیل تفاوتهای مختصری که دارند، گفته شد که این تگها دقیقا HTML نیستند. برای مثال در تگهای HTML خاصیتهای class و for را داریم؛ اما در تگهای JSX باید به ترتیب از className و htmlFor استفاده کنیم. مسئله بعدی این است که اساسا JSX همراه با React ارائه نشده و برای اینکه بتوانیم از JSX استفاده کنیم، نیاز به ابزاری اضافه داریم تا JSX را برای JavaScript و مرورگر ترجمه کند که فیسبوک، Babel را پیشنهاد میدهد. اگر از JSX بدون ابزار مترجم استفاده کنیم با پیام خطای زیر مواجه میشویم.
> Uncaught SyntaxError: Unexpected token
یعنی کاراکتر شروع (>) تگها را تشخیص نمیدهد.
نصب کتابخانهها
این کتابخانهها را میشود به مدلهای مختلفی دریافت و پیکربندی کرد. بسته به نوع پروژه و محیط توسعه و پیکربندیهای خاص هر پروژه، روش کار میتواند متفاوت باشد. هدف اصلی، مروری بر امکانات React است. پس سادهترین روش نصب را برای ادامه کار انتخاب میکنیم. مانند هر کتابخانهی دیگری میشود بطور یکجا React و Babel را از سایتهای اصلی یا Github دانلود و به پروژه اضافه و استفاده کرد؛ مثل jQuery و Bootstrap. اما راه استاندارد و پیشنهاد شده، استفاده از ابزارهای مدیریت بستهها مثل npm است. در قدم اول با فرض بر اینکه VSCode و npm بر روی سیستم نصب هستند، اول یک پوشه خالی را در VSCode به عنوان پروژه باز میکنیم و از منوی View -> Integrated Terminal را انتخاب میکنیم. در ترمینال باز شده دستور نصب زیر را وارد میکنیم.
npm install react react-dom
npm install babel-standalone
نحوه استفاده
فایل index.html را به ریشه پروژه اضافه کنید و کدهای زیر را درون تگ Body قرار دهید:
<div id="reactTestContainer"></div> <script src="node_modules/react/dist/react.min.js"></script> <script src="node_modules/react-dom/dist/react-dom.min.js"></script> <script src="node_modules/babel-standalone/babel.min.js"></script> <script src="react-test.js" type="text/babel"></script>
برای کار با کتابخانه React به دو فایل react.js و react-dom.js نیاز داریم. اولی بخش اصلی کتابخانه و دومی برای ساخت تگها و تبادل با بخش HTML DOM استفاده میشود؛ مثلا اضافه کردن تگهای ساخته شده به HTML. ذکر ویژگی "type="text/babel برای فایلهایی که در آنها از تگهای JSX استفاده شده ضروری است؛ در غیر اینصورت Babel تشخیص نمیدهد که کار ترجمه را برای چه فایلهایی باید انجام دهد. در نهایت قطعه کد زیر را در فایل react-test.js وارد کنید.
var ClickableImage = function (props) { return ( <a href={props.href}> <img src={props.src} /> </a> ) }; ReactDOM.render( <ClickableImage href="http://google.com" src="google.jpg"/>, document.getElementById("reactTestContainer") )
با اجرا کردن پروژه، تصویری قابل کلیک به مقصد گوگل، در تگ <div>، با ویژگی "id=”reactTestContainer ایجاد خواهد شد.
تا به این قسمت متوجه شدیم که کتابخانه React چیست و چطور میشود از آن استفاده کرد. در قسمت بعد نگاهی دقیقتر به کامپوننتهای React خواهیم داشت.