مزایا و معایب Membership

[mohsen_zelzela00]

با سلام
دوستان اگه ممکنه مزایا و معایب استفاده از کنترل های login و createuser خود Asp.net رو در این تاپیک دکر کنید تا کسانی که بخوان از Membership استفاده کنند بدانند چه معایب و مزایایی دارد

پیشاپیش ممنون

[mohsen_zelzela00]

اساتید محترم آیا در این ضمینه نطری ندارند؟؟؟؟؟؟

[Mostafa_Dindar]

اساتید محترم آیا در این ضمینه نطری ندارند؟؟؟؟؟؟
نظر همه خوب هست

[Peyman.Gh]

معایب ما ندیدیم ازش

[حامد مصافی]

membership براي مقصود محدودي طراحي شده به همين دليل اطلاعات كاربران (profileCommon) به صورت سريالي در ديتابيس نگهداري مي شود، اولين ايراد اين سيستم عدم امكان درج شرط پرس و جو براي پروفايل است، براي مثال اگر در پروفايل فيلدي با عنوان شهرستان محل سكونت درج كرده باشيد براي اينكه كاربران يك شهرستان خاص را ليست كنيد بايد در كل ليست كاربران پيمايش كنيد. طبق يك اصل كلي در سيستم هاي عمومي محدوديت هاي نا گزيري پديد مي آيد كه در انجام اعمال خاص خارج از محدوده عمومي خود نمايي مي كند، اما براي يك پروژه كوچك استفاده از امكانات asp.net membership مي تواند موجب كاهش زمان توسعه شود مگر اينكه بخواهيد تسلط كامل بر اعمال پشت پرده داشته باشيد.

[mohsen_zelzela00]

معایب ما ندیدیم ازش
دوستان عزیز اگه یک سری مزایا داره ممنون میشم مزایای آن هم ذکر بشه که اگر دوستان بخواهند از آن استفاده کنند مزایا و معایب آن در اینجا ذکر شده باشه و بنونن راحت تر تصمیم بگیرند

[Peyman.Gh]

بنظرم استاندارد طراحی شده وقتی ما از Web Site Administration Tool استفاده میکنیم بانک اطلاعاتی جامع و کاملی برای ما میسازد که همه چیز در آن مشخص شده است و و به درستی تعریف شده است.

[raziee]

membership براي مقصود محدودي طراحي شده به همين دليل اطلاعات كاربران (profileCommon) به صورت سريالي در ديتابيس نگهداري مي شود، اولين ايراد اين سيستم عدم امكان درج شرط پرس و جو براي پروفايل است، براي مثال اگر در پروفايل فيلدي با عنوان شهرستان محل سكونت درج كرده باشيد براي اينكه كاربران يك شهرستان خاص را ليست كنيد بايد در كل ليست كاربران پيمايش كنيد. طبق يك اصل كلي در سيستم هاي عمومي محدوديت هاي نا گزيري پديد مي آيد كه در انجام اعمال خاص خارج از محدوده عمومي خود نمايي مي كند، اما براي يك پروژه كوچك استفاده از امكانات ASP.NET membership مي تواند موجب كاهش زمان توسعه شود مگر اينكه بخواهيد تسلط كامل بر اعمال پشت پرده داشته باشيد.

با سلام
فرمایش شما کاملا صحیح اما برای ایجاد پروفایل یک کاربر بهتر هست که خود برنامه نویس بیاد و پروفایل مروبطه رو خودش بسازه (منظور ایجاد یک جدول به نام پروفایل هست). و با اون جدولی که خودش ساخته کار کنه.

از نظر امنیت مخصوصا برای دوستانی که تسلط زیادی بر روی مبحث امنیت ندارند بهتره که از ممبرشیپ خود دات نت استفاده کنند.
من که در هر کجا خوندم و از هر کسی شنیدم استفاده از این روش رو پیشنهاد دادند.
حالا برای بهبود کار خودتون میتونید اون رو تغییر و یا اصلاح کنید.
برای بدست آوردن اطلاعات کافی در این ضمینه کتاب بسیار عالی :
Professional ASP.NET 2.0 Security, Membership, and
Role Management
Published by
Wiley Publishing, Inc.
10475 Crosspoint Boulevard
Indianapolis, IN 46256
www.wiley.com
Copyright © 2006 by Wiley Publishing, Inc., Indianapolis, Indiana
Published simultaneously in Canada
ISBN-13: 978-0-7645-9698-8
ISBN-10: 0-7645-9698-5
Manufactured in the United
رو مطالعه کنید.
خوندنش رو پیشنهاد میکنم. 640 صفحه

[حامد مصافی]

رمایش شما کاملا صحیح اما برای ایجاد پروفایل یک کاربر بهتر هست که خود برنامه نویس بیاد و پروفایل مروبطه رو خودش بسازه (منظور ایجاد یک جدول به نام پروفایل هست). و با اون جدولی که خودش ساخته کار کنه.
سلام
اگر عرايض بنده رو خونده باشيد من هم نظرم بر اينه كه براي سايت هاي بزرگ تر نوشتن برنامه اين قسمت ها توسط خود برنامه نويس بهتره، نه فقط پروفايل بلكه حتي membership

[Omid.Mafakher]

-------------------------------------

[حامد مصافی]

معماری این سیستم بسیار زیبا است. امکاناتی که دارد به حدی کامل است که بتواند از بزرگترین پرژه ها را جوابگو باشد تا کوچکترین آنها.
امکانات فوق العاده این سیستم به خاطر استفاده از معماری Provider است، این سیستم به شما این قابلیت را می دهد که ارتباط با دیتابیس را شما در دست بگیری.
اگر Web.Config را دیده باشید، در بخش system.web یک Section وجود دارد با نام membership که دارای اطلاعاتی اعم از ConnectionString و تنظیماتی برای خود این سیستم است، در کنار اونها یک attribute به نام type وجود دارد که اون نشانگر آدرس فایل و کلاس مدیر دیتابیس است.
حالا اگر دیده باشید برای Profile و Role این قابلیت جداگانه گذاشته شده.
برنامه نویس های حرفه ای برای سایت های بزرگ از معماری خودشون توی این سیستم استفاده می کنن.
به این آدرس برید تا بیشتر با این معماری آشنا بشید:
Profile Provider with LINQ (http://www.codeproject.com/KB/aspnet/LINQCustomProfileProvider.aspx)
فرموديد مي تواند بزرگ ترين پروژه ها را جواب گو باشد اما دليلي ارائه نكرديد

[Omid.Mafakher]

-------------------------------------

[حامد مصافی]

Asp.Net membership يك platform نيست، حتي جزئي از دات نت هم نيست، بلكه يك افزونه براي Config توسط asp.net است.
درست است كه دست برنامه نويس را در بسياري از ضمينه ها باز گذاشته است اما در بسياري موارد هم علي الخصوص پروژه هاي بزرگ تر موجب محدوديت دامنه فعلي كد هاي برنامه نويس مي شود. همانطور كه قبلاً به عرض رسوندم در پروژه هاي كوچك و متوسط مي توان از اين قابليت استفاده كرد، اما كمتر برنامه نويس حرفه اي ديدم كه از اين قابليت در يك پروژه بزرگ استفاده كند.
در يك پروژه بزرگ نيازمند اين هستيد تا كنترل كاملي بر آنچه كه بايد اتفاق بيفتد داشته باشيد.

[Mostafa_Dindar]

تا جايي كه من مطالعه كردم معماري ASP.NET 2.0 Membership در عين حال كه استفاده از اون ميتونه ساده باشه كاملا Customizable هست و براي مقاصد و نياز متفاوت امكان شخصي سازي دارد و پروژه هاي بزرگ رو هم به خوبي جواب داده . و جالب اينكه بر خلاف ديگر ويژگيهايي كه دات نت براي برنامه نويسان فراهم كرده كه مخالف و موافقان بسياري دارد ، در اين ضمينه اكثرا از اون حمايت كردند .

در اين كه اين معماري موفق بوده شكي نيست ولي دليلي ندارد كه يك معماري موفق بتونه همه و همه نيازها رو پاسخ بده .

نكته جالب ديگري كه هست ، معادلي يا رقيبي براي اون نيست كه بخواهيم با اون مقايسه كنيم . پس اگر در شرايطي اين معماري به طور ايده آل جوابگوي كار ما نيست و نياز داريم معماري خاص خودمان رو پياده سازي كنيم بايد هزينه زيادي پرداخت كنيم كه بسيار قابل ملاحظه خواهد بود ( هميشه هزينه رو در نظر بگيريد ) و به احتمال خيلي زياد به پايداري معماري پيشنهادي مايكروسافت نخواهد رسيد .


در اينكه شما ميفرمائيد كمتر برنامه نويس حرفه اي ميشناسيد از اين معماري استفاده كنند ، بايد اين نكته رو هم مد نظر داشته باشيد كه استفاده از معماري ، تكنولوژي يا هر چيز جديد نيازمند هزينه (زمان براي يادگيري) هست . و شايد اون عده از برنامه نويسهاي حرفه اي مد نظر شما هنوز اون هزينه رو پرداخت نكردند و ترجيح ميدهند با معماري كاملا آشناي خودشان كار كنند .

[Peyman.Gh]

بنظر WAT از لحاظ معماری کامل میباشد اما ممکن گاهی اوقات دست برنامه نویس را ببندد چون برنامه نویس از معماری آن اطلاعی ندارد اما در حال حاضر جواب گوی پروژه های سبک میباشد.

[حامد مصافی]

هميشه هزينه رو در نظر بگيريدهميشه؟ پس يك برنامه نويس php كه تمام كد ها را خودش مي نويسد هزينه را در نظر نمي گيرد. براي مثال همين فاروم VB كه مي توانست با ASP.NET و ابزار هاي آماده ان زمان كد نويسي را به 1/5 تقليل بده، هزينه را در نظر نگرفته است.



در اينكه شما ميفرمائيد كمتر برنامه نويس حرفه اي ميشناسيد از اين معماري استفاده كنند ، بايد اين نكته رو هم مد نظر داشته باشيد كه استفاده از معماري ، تكنولوژي يا هر چيز جديد نيازمند هزينه (زمان براي يادگيري) هست . و شايد اون عده از برنامه نويسهاي حرفه اي مد نظر شما هنوز اون هزينه رو پرداخت نكردند و ترجيح ميدهند با معماري كاملا آشناي خودشان كار كنند .زمان يادگيري استفاده از اين تكنولوژي به مراتب كمتر از زمان يادگيري علمي براي نوشتن جايگزين هاي آن است.


تكنولوژه فوق در چهارچوبي كه طراحي شده عاليه، اما اگر كسي بخواهد نياز هاي ديگري بدان اضافه كند.
مثل دريافت كلمه عبور جديد و امكان ورود با هر دو كلمه عبور، نمايش ليست كاربران با جزئيات پروفايل و امكان سورت (مانند صفحه كاربران اين فاروم)، انتخاب اينكه در DB نام كاربر كليد باشد يا ID (براي مواردي مانند Link يا Relation ) امكان جستجوي كاربران با شرايط پروفايل و هر چيز ديگري كه در اين چهارچوب نيست، ممكن نخواهد بود.

[Behrouz_Rad]

من با حامد مصافی "تا حدودی" موافقم. من معماری خودم رو دارم. حرف برادر مصافی برای من قابل پذیرش تره که این معماری در پروژه های بزرگ "شاید" کم بیاره. عبارت "شاید" رو برای این استفاده می کنم چون با "پیکربندی پیش فرضی" که داره این رو میگم. نکاتی که برای افزایش کارایی و سرعت SP ها و بهینه سازی های جداول Membership باید صورت بپذیره به خوبی انجام نشده.
توجه دوستان رو به دو قسمت از مقاله ی ذیل که توسط برادر Omar Al Zabir نوشته شده جلب می کنم:
http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx



Optimize ASP.NET 2.0 Profile provider
How to query ASP.NET 2.0 Membership tables without bringing down the site



Do you know there are two important stored procedures in ASP.NET 2.0 Profile Provider
that you can optimize significantly? If you use them without doing the necessary optimization,
your servers will sink taking your business down with you during heavy load. Here's a story:

During March, Pageflakes was shown on MIX 2006. We were having a glamorous time back then.
We were right on Showcase of Atlas Web site as the first company.
Number of visits per day were rising sky high. One day we noticed, the database server was no more.
We restarted the server, brought it back, again it died within an hour.
After doing a lot of postmortem analysis on the remains of the server's body parts,
we found that it was having 100% CPU and super high IO usage. The hard drives were over heated and turned themselves off in order to save themselves.

این قسمت مهمه که میگه:


Number of visits per day were rising sky high

یعنی از Membership در یک سیستم با مراجعه ی بالا استفاده شده.

من به شخصه وقتی که مشکلاتی به این صورت رو در محصولی می بینم حس بدی نسبت به اون بهم دست میده و خیلی سخت می تونم خودم رو به استفاده از اون حتی در صورتی که راه حلی برای رفع مشکلات اون وجود داشته باشه قانع کنم. شاید در پشت پرده هم مشکلات دیگه ای وجود داشته باشن که قابل کشف نباشن!

موفق باشید.

[reza_62]

آقای راد تشکر من می خواستم از این روش استفاده کنم که شما مرا مردد کردید

[Alireza_Salehi]

همان طور که بسیاری از دوستان فرمودند در پروژه های کوچک و متوسط مشکلی نخواهید داشت، بنده به شخصه استفاده زیادی از Membership کرده ام و مشکلی نداشته ام.
اما این استفاده شرایطی داشته یعنی برخی یک سری SP بهش اضافه کردیم تا سرعت اجرای بعضی کارها بالاتر بره یا بعضی sp هاش رو دستکاری کردیم تا بهتر بشه.
Membershipدر خیلی از موارد جوابگو هستش و به راحتی با افزودن چند جدول به دیتابیس می توانید کمبود های آن را جبران کنید.

این نکته رو هم ذکر کنم که توسعه Forms Authentication خیلی کار پیچیده ای نیست، شما میتونید Provider دلخواهتون رو مبتنی بر Forms Authentication توسعه بدید و قابلیتهایی که در Membership وجود نداره پیاده سازی کنید. حتی اگر بخواهید می توانید اصلا از مدل Provider استفاده نکنید.



هر چند این کار فقط به افرادی توصیه میشه که تسلط کافی به برنامه نویسی و اصول امنیتی وب داشته باشند. در غیر این صورت عدم آگاهی باعث ایجاد حفره های جدی میشه.

[h.alizadeh]

امنیت سیستم میبرشیپ به نظرشما چطوره؟خوبه؟یامستعد هک و ایناس؟

[mehdi.mousavi]

سلام.
من با این حرف که "برای پروژه های بزرگ" با این سیستم به مشکل بر می خورید، موافق نیستم. صحبتهای Omar Al Zabir هم در مورد Tune کردن Profile Provider ها هستش که همگان به این مساله واقف هستند که تو این بخش، مایکروسافت واقعا کم کاری کرده.

اما این به این معنی نیستش که شما نمی تونید Profile Provider خودتون رو بنویسید. شما میتونید یه Custom Profile Provider درست کنید و داده ها رو، طبق نیاز خودتون، توی یه custom database schema ذخیره (یا بازیابی) کنید. بدین ترتیب شما از همون API های موجود برای کار با Profile ها استفاده خواهید کرد، اما داده ها رو بطرز مناسبی توی بانک می تونید بریزید و دیگه مجبور نیستید داده ها رو بصورت Bulk و Colon-Separated نگهداری کنید.

ضمن اینکه کسانیکه از Profile Provider شکایت دارن، باید بدونن که Profile ها در کجای Page Life Cycle قرار میگیرن:


بار اولی که به Profile ها دسترسی پیدا می کنید، داده های مربوطه از بانک برای کاربر فعلی خونده میشه، و تا وقتی Postback ای رخ نداده، داده ها از توی Memory (برای فراخوانی های بعدی) در دسترس قرار میگیرن.
یکبار هم هنگامی که پردازش صفحه تموم شده، Update ها اعمال میشن و تمام. یعنی در واقع شما 5 دفعه هم که اطلاعات Profile رو تغییر بدید (منظورم در یک Request-Response هستش)، کل این Update ها بصورت differed کار میکنن، یعنی عمل Update به تعویق میفته تا پردازش صفحه تموم بشه. وقتی شد، هر 5 تغییر توی یکبار رجوع به بانک Update میشه.

بدین ترتیب، اگر از Profile ها هم تو برنامه زیاد استفاده نشده باشه (بر اساس پیاده سازی پیش فرض)، خیلی دشوار هستش که بشه در مورد Performance این بخش نظر داد. اما اگر Profile ها رو در ASP.NET کنار بذاریم، بخش Membership اون واقعا خوب و عقلانی نوشته شده و اگر هم بخشهایی وجود داره که Functionality اش بر اساس نیاز شما نیست، میتونید اون بخشها رو Extend کنید و از همون Membership API ها برای کار در پروژه استفاده کنید. بدین ترتیب، فردا روزی اگر نیاز باشه تا اطلاعات Memership رو در مثلا Active Directory، یا جای دیگه نگهداری کنید، دیگه نیازی به تغییر کدهاتون ندارید و با تغییر در فایل web.config این امر به سهولت امکانپذیر خواهد بود.

موفق باشید.

[Behrouz_Rad]

صحبتهای Omar Al Zabir هم در مورد Tune کردن Profile Provider ها هستش که همگان به این مساله واقف هستند که تو این بخش، مایکروسافت واقعا کم کاری کرده.

پس Profile ها در حالت پیش فرض مشکل دارن درسته؟ منظور از "همگان" چه کسانی هستند؟ من که ندیدم افرادی که در این تاپیک پست دادند به این موضوع اشاره ای کرده باشند. این افراد مطمئناً جزء "همگان" هستند.

وقتی که یک فناوری، یک تکنولوژی، یک ابزار یا هر چیز دیگه ای که اسمش رو میگذاری عرضه میشه، من به عنوان استفاده کننده به اون اطمینان می کنم و قصد بر استفاده از اون در پروژه ای می کنم که منبع مالی زندگی من میشه.
اگر من یک مسافرکش باشم و پژویی رو از ایران خودرو می خرم، انتظار دارم که اون خودرو تمامی قطعاتش با کیفیت خوب و بدون مشکل باشن. نه اینکه اگر به پمپ بنزین رفتم و در حال زدن بنزین بودم، ماشین من منفجر بشه و من و خودش رو به تلی از خاکستر تبدیل بکنه، یا در حالت خفیف تر، توی بنزین، آب باشه!

وقتی که ارائه دهنده ی محصول بدون بررسی کیفی محصول اون رو عرضه می کنه و اگر هم بعداً متوجه مشکل شد از بیان مشکل خودداری کنه تا اینکه فردی بیاد و ادعای کمبود در اون محصول رو بکنه برای من فایده ای نداره. چون هزینه ی اضافه ای رو برای رفع مشکل به من تحمیل می کنه. ضمن اینکه من تا به حال ندیدم تیم ASP.NET برای رفع این مشکل که به قول شما" همگان" به اون واقف هستند، وصله ای عرضه کرده باشه. اگر دیدی بگو.



بخش Membership اون واقعا خوب و عقلانی نوشته شده

احتمالاً بخش دوم اون مقاله رو نخوندی. به کمبود Index ها در جداول توجه کردی؟ جداول و SP ها چیز جدایی از کلاس ها و کدهای برنامه نیستند.
اگر قرار هست که من هم جداول و هم SP های خودم رو tune کنم و هم مال ASP.NET رو، پس چه نفعی عاید من شده؟ چرا یک روال واحد برای "همگان" وجود نداشته باشه؟!

توجه داشته باش که یک سیستم برای محبوبیت خودش باید تمامی افراد را در هر سطح سوادی در نظر داشته باشه. چند درصد افراد به Index ها توجه می کنند؟ حداقل باید پیش فرض هایی در سیستم بر اساس استانداردهایی که وجود داره در نظر گرفته بشه.

موفق باشید.

[Mostafa_Dindar]

من تصور ميكنم منظور آقاي موسوي از "همگان" افراد باتجربه اي هستند كه پروژه هاي Enterprise اي رو انجام داده اند و در سطح مقاله معرفي شده (Omar Al Zabir) هستند نه "همگان" به معناي عام .

[Behrouz_Rad]

من تصور ميكنم منظور آقاي موسوي از "همگان" افراد باتجربه اي هستند كه پروژه هاي Enterprise اي رو انجام داده اند و در سطح مقاله معرفي شده (Omar Al Zabir) هستند نه "همگان" به معناي عام .
منظور باید واضح منتقل بشه. خودت رو دست کم نگیر پسر. :چشمک:

[h.alizadeh]

مثال آقا بهروز منو یاد حرفای اون شرکت خودروسازه و بیل گیتس کرد. :لبخند:

---

من یک بار از سیستم میبرشیپ استفاده کردم (امتحانی) بعد رفتم توی هاست و جداولشو اونجا ریختم بعد مقدار رکوردها رو از طریق sql server management studio انتقال دادم ولی میبرشیپ روی هاست کار نمیکرد...
اینم هست باید میگند مقدار رکوردهاشو هم با پشتیبان گیریم انتقال بدیم...


خب بابا کسی در مورد امنیتش حالا چیزی نمیگه؟
مثکه خیلی بده این میبرشیپ که اینقدر شوته که دیگه به بحث امنیتش نمیشه رسید...!:بامزه:

[Behrouz_Rad]

من یک بار از سیستم میبرشیپ استفاده کردم (امتحانی) بعد رفتم توی هاست و جداولشو اونجا ریختم بعد مقدار رکوردها رو از طریق sql server management studio انتقال دادم ولی میبرشیپ روی هاست کار نمیکرد...

این مشکل خیلی ها است. باید قبل از هر کاری مقدار applicationName رو به تگ add که از تگ های سکشن membership در فایل Web.Config هست اضافه کنی. چون این مقدار در جدول aspnet_Applications قرار می گیره و بدین طریق میشه فهمید که کدام رکورد مربوط به کدام پروژه است. یا می تونی جدول aspnet_Application رو باز کنی و مقدار فیلد ApplicationName رو نگاه کنی و مقدارش رو به خاصیت applicationName که در بالا گفتم نسبت بدی.


کسی در مورد امنیتش حالا چیزی نمیگه؟

امنیتش به نظر من خوبه.

موفق باشید.

[reza_62]

آقای راد شما مقاله یا پروژه سورس بازی را سراغ دارید که خدومون membership خودمونو بنویسیم

[h.alizadeh]

این مشکل خیلی ها است. باید قبل از هر کاری مقدار applicationName رو به تگ add که از تگ های سکشن membership در فایل Web.Config هست اضافه کنی. چون این مقدار در جدول aspnet_Applications قرار می گیره و بدین طریق میشه فهمید که کدام رکورد مربوط به کدام پروژه است. یا می تونی جدول aspnet_Application رو باز کنی و مقدار فیلد ApplicationName رو نگاه کنی و مقدارش رو به خاصیت applicationName که در بالا گفتم نسبت بدی.

ممنون،
ببخشید میشه بگید دقیقاً این تگ اد کجاس؟و چطوری بهش اضافه کنم؟:خجالت:
من رفتم داخل این جدول که گفتید، مقدار applicationName برابر یک اسلش(/) بود فقط فکر کنم منظور شما ApplicationId باشه ،آره؟

[Behrouz_Rad]

آقای راد شما مقاله یا پروژه سورس بازی را سراغ دارید که خدومون membership خودمونو بنویسیم

http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx


ممنون،
ببخشید میشه بگید دقیقاً این تگ اد کجاس؟و چطوری بهش اضافه کنم؟:خجالت:
من رفتم داخل این جدول که گفتید، مقدار applicationName برابر یک اسلش(/) بود فقط فکر کنم منظور شما ApplicationId باشه ،آره؟
خیر، منظورم همون ApplicationName هست. بعد از اسلش یک نام دلخواه قرار بده. مثلاً:


/myAppName

در فایل Web.Config:


<membership>
<providers>
<clear/>

<add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
<!-- بقیه ی مقادیر -->
applicationName="/myAppName" />
</providers>
</membership>

عبارت myAppName/ رو در مقدار فیلد ApplicationName هم قرار بده.

موفق باشید.

[reza_62]

یعنی شما گفتید من خودم یک membership برا خودم دارم یک custom membership نوشته اید مثل این مقاله؟
تشکر

[Behrouz_Rad]

یعنی شما گفتید من خودم یک membership برا خودم دارم یک custom membership نوشته اید مثل این مقاله؟
تشکر
خیر. من از FormsAuthentication که در ASP.NET 1.x معرفی شد استفاده می کنم. کلاس های Low-Level اش. Membership Provider یک Wrapper برای این کلاس ها است.

موفق باشید.

[reza_62]

خیلی تشکر چون من تصمیم داشتم وقت بزارم روی این membership
ولی اون اتفاقی که برای omar al bazir افتاد من رو پشیمون کرد

[h.alizadeh]

ممنون آقا بهروز،
پس همین کد رو اینجوری اضافه کنیم و بعد جداول رو در سرور قرار بدیم بعدمقدار رکوردها رو از طریق sql server management studio انتقال، کار میکنه دیگه؟ نه؟(الان روی هاست ندارم چک کنم.:چشمک:)


ببخشید من یک مقداری سؤال میکنم؛

چون این مقدار در جدول aspnet_Applications قرار می گیره و بدین طریق میشه فهمید که کدام رکورد مربوط به کدام پروژه است.
ببخشید من این جدول aspnet_applicationرو زیاد خوب نفهمیدم واسه چیه؟ یعنی چی تشخیص بدیم کدوم پروژه ؟یعنی چی روی چندتا پروژه ؟

[Omid.Mafakher]

-------------------------------------

[reza_62]

یعنی شما هم معماری membership را قبول ندارید؟

[Omid.Mafakher]

-------------------------------------

[mohsen_zelzela00]

اگر منظورتون با من بود، من قبول داریم چون معماری اون هیچ ایرادی نداره.

دوست عزیز پس چی میشه بیشتر توضیح بدید ؟؟؟(البته اگه با نمونه کد باشه خیلی بهتره)
ممنون

[mehdi.mousavi]

سلام.

@Lastphoenix: دقیقا منظورم افرادی بود که 4 تا کار در سطح Enterprise انجام داده باشن و واقعا بدونن که چیکار میکنن. والا پر واضحه که منظور من از "همگان"، افرادی نبودن که هنوز فرق public و private رو نمیدونن و همش دور خودشون میچرخن. جالب اینه که در دو کتابی که من در مورد ASP.NET خونده ام، هر دو نویسنده به وضوح در مورد بخش Profiles به خواننده هشدار دادن و در مورد Performance این بخش، نحوه نگهداری اطلاعات بصورت پیش فرض، و چگونگی Extend کردن این بخش، به خوبی توضیح میدن...

@بهروز راد: :لبخند:

@Omid.Mafakher: در مورد Omar Al Zabir و مقالاتی که ایشون روی CodeProject گذاشته، کم لطفی کردید. من نمیدونم طرف رو میشناسید یا نه، اما با سن کمی که داره، آدم sharp ای هستش و تجربه خوبی در زمینه ASP.NET داره. برای جاهای بزرگی کار کرده و ... در هر حال، فکر نمیکنم ملیت آدمها، تاثیری در صحبتهای فنی اونها داشته باشه.

موفق باشید.

[Mostafa_Dindar]

در تكميل توضيحات آقاي موسوي كتاب Building a Web 2.0 Portal With ASP.NET 3.5 (http://oreilly.com/catalog/9780596510503)

http://covers.oreilly.com/images/9780596510503/cat.gif

از تاليفات آقاي Omar AL Zabir (http://www.oreillynet.com/pub/au/2970) هست كه كتاب قابل ملاحظه اي هست .

ولي همانطور كه آقاي اميد مفاخر گفتند :


من از دوستان خواستم که توضیح بدن که در پرژه بزرگ چه کاری برای بالا رفتن Performance برنامه اشون می کنن تا من اونها رو قانع کنم اما خبری از جواب نشدحرف حساب ميگه !

ما كه كوچيكيم ، لطفا بزرگان پاسخگو باشند :لبخند:

[Behrouz_Rad]

من از دوستان خواستم که توضیح بدن که در پرژه بزرگ چه کاری برای بالا رفتن Performance برنامه اشون می کنن تا من اونها رو قانع کنم

من یک TODO List دارم. بلند بالاست. فکر نمی کنم ارتباطی با بحث داشته باشه. ما در مورد Membership صحبت می کنیم. اما اگر هدف مقایسه بین کارهایی هست که من در بحث Membership سفارشی خودم انجام میدم و اونهایی هست که Built-in در Membership Provider وجود داره می تونیم در موردشون بحث کنیم.


آقای راد هرکس که یک مقاله رو روی CodeProject بزاره دلیل بر این نیست که اون شخص درست گفته، نظر شخصیه خودش رو گذاشته، حالا چون ایرانی نیست یعنی داره درست میگه؟؟؟؟!!!!

ازت بعیده! ;) پاسخ من به این حرفت، پست قبلی برادر موسوی هست.



ببینید دوستان و مخصوصاً آقای راد دوست قدیمی من، همونطور که میدونید تجربه کاری من در برنامه نویسی روی دات نت از زمان بوجود آمدن این تکنولوژی بوده

@امید مفاخر: کجا بودی برادر؟ دلم واست خیلی تنگ شده :X
اینو من می دونم، بقیه که نمی دونن ;)

[reza_62]

آقای راد اگر آن todo list را بزارید ممنون می شوم

[Behrouz_Rad]

آقای راد اگر آن todo list را بزارید ممنون می شوم
TODO list یک مورد شخصی و بلند بالاست که از مراجع مختلف گردآوری و از بخش های مختلفی تشکیل شده اما می تونم قسمتی از بخش Membership اون رو که فقط مربوط به "کلمه ی عبور" هست بگذارم:
1) مکانیزمی برای جلوگیری از ایجاد کلمات عبور ساده در سیستم داشته باشید. مثلاً 123456789 یک کلمه ی عبور ساده ست که موجب Account Hijacking میشه.
2) طول کلمه ی عبور بهتر است حداقل 8 و حداکثر 100 کاراکتر باشد. (تعیین حداقل برای طول کلمه ی عبور موجب میشه تا شانس حملات Brute force کاهش پیدا کنه)
3) مانع ورود کاراکتری خاص توسط کاربر به عنوان کلمه ی عبور نشید.
4) نام کاربری و کلمه ی عبور نباید یکی باشند.
5) اگر کلمه ی عبور رو خودتون تولید می کنید الگوریتمش ثابت نباشه. مثلا اینجور نباشه که کلمه ی عبور از نام کاربری + عدد 22 تشکیل شده باشه!
6) از کلمات عبور معروف برای مدیر سایت استفاده نکنید. مثلاً admin یا web master. چون موجب نوعی از حملات با عنوان Social Engineering میشه.
7) اکانت هایی که برای مدت مشخصی استفاده نشدند رو غیر فعال کنید.
8) کلمات عبور رو Hash کنید.
9) بسته به اهمیت سیستم میشه به کاربران هشدار داد که کلمه ی عبورشون رو در بازه های زمانی مختلف عوض کنند. البته در این حالت نیاز به یک Password History هست تا کاربر کلمات عبور قبلیش رو مجدداً انتخاب نکنه.
10) قبل و بعد از تغییر کلمه ی عبور کاربر رو مجبور کنید تا مجدداً در سیستم لوگین کنه.

اینها 10 مورد از مهمترین ها فقط برای بخش "کلمه ی عبور" بودند.

موفق باشید.

[reza_62]

آقای راد این که خیلی عالی بود اگه برای دیگر بخشهای پیاده سازی یک membership
todo list بزارید ممنون می شوم ( البته پر رویه ) ولی این todolist خیلی خوب بود.

[mahdi_farhani]

مزایا : استفاده راحت ، سرعت پیاده سازی بالا
معایب :
همانطور که دوستان گفتن بهینه نبودن sp ها و جداول
راحت طلب کردن برنامه نویس که این خودش از نظر من این بزرگترین مشکل (کلاً من با ساختار ویزارد مشکل دارم)

حالا یک سوال از دوستانی که از membership استفاده کردن ، من نیاز به ایجاد این ساختار هستم ( که پایین توضیح میدم) آیا امکان پیاده سازیش با Membership دات نت هست یا نه ؟ اگر هست چقدر بهینه هست ؟

فرض کنید تعداد n نقش (Role) داریم ، حال من نیاز دارم که این نقشها به یکسری از منابع سیستم دسترسی پیدا کنند . ولی من نیاز به سطح دسترسی دارم که بتوانم بگم که کدوم نقش یا فرد به کدام یک از کلید های عملیاتی (مثل درج ، ویرایش ، حذف ) دسترسی داشته باشد .....
و یا نیاز دارم که یکسری از نقشها در ساعتی خاص از به این ماژول های دسترسی داشته باشند ....

به طور مثال :
نقش : مدیران ارشد
اجازه دسترسی به صفحه مدیریت کاربران را دارند ، اجازه درج کاربر جدید را دارند ، اجازه حذف کاربران دارند ، اجازه ویرایش کاربران را دارند ، اجازه دادن مجوز شروع کار به کاربر را دارند ، اجازه اخراج کاربر را دارند
---------
نقش : مدیران جز
اجازه دسترسی به صفحه مدیریت کاربران را دارند ، اجازه درج کاربر جدید را دارند ، اجازه حذف کاربران ندارند، اجازه ویرایش کاربران را ندارند، اجازه دادن مجوز شروع کار به کاربر را ندارند، اجازه اخراج کاربر را ندارند

----------------------------------------------------------------------------
سوال دوم که همین الان به ذهنم رسید
من یک سیتسم دارم که از بانک اطلاعاتی توزیع شده استفاده میکنه ، جدول کاربران من به دلایلی شکسته شده و در پایگاه های دیگر قرار داره ، حالا آیا سیستم Membership از این حالت پشتیبانی میکند ؟؟!

این دوتا سوال مواردی هست که در پروژه های بزرگ ممکنه (وابسته به معماری و نوع پروژه و ..... داره) پیاده سازی بشه و اگر Membership این امکان را نداشته باشه که کلاً قضیه منتفی محسوب میشه .
شاید دوستان بگن این موارد ، موارد استثناء هست و برای همگان پیش نمیاد ،ولی من میگم برای من که پیش اومده پس من استفاده نمیکم ......

[Alireza_Salehi]

مزایا : استفاده راحت ، سرعت پیاده سازی بالا
معایب :
همانطور که دوستان گفتن بهینه نبودن sp ها و جداول
راحت طلب کردن برنامه نویس که این خودش از نظر من این بزرگترین مشکل (کلاً من با ساختار ویزارد مشکل دارم)

حالا یک سوال از دوستانی که از membership استفاده کردن ، من نیاز به ایجاد این ساختار هستم ( که پایین توضیح میدم) آیا امکان پیاده سازیش با Membership دات نت هست یا نه ؟ اگر هست چقدر بهینه هست ؟

فرض کنید تعداد n نقش (Role) داریم ، حال من نیاز دارم که این نقشها به یکسری از منابع سیستم دسترسی پیدا کنند . ولی من نیاز به سطح دسترسی دارم که بتوانم بگم که کدوم نقش یا فرد به کدام یک از کلید های عملیاتی (مثل درج ، ویرایش ، حذف ) دسترسی داشته باشد .....
و یا نیاز دارم که یکسری از نقشها در ساعتی خاص از به این ماژول های دسترسی داشته باشند ....

به طور مثال :
نقش : مدیران ارشد
اجازه دسترسی به صفحه مدیریت کاربران را دارند ، اجازه درج کاربر جدید را دارند ، اجازه حذف کاربران دارند ، اجازه ویرایش کاربران را دارند ، اجازه دادن مجوز شروع کار به کاربر را دارند ، اجازه اخراج کاربر را دارند
---------
نقش : مدیران جز
اجازه دسترسی به صفحه مدیریت کاربران را دارند ، اجازه درج کاربر جدید را دارند ، اجازه حذف کاربران ندارند، اجازه ویرایش کاربران را ندارند، اجازه دادن مجوز شروع کار به کاربر را ندارند، اجازه اخراج کاربر را ندارند

----------------------------------------------------------------------------
سوال دوم که همین الان به ذهنم رسید
من یک سیتسم دارم که از بانک اطلاعاتی توزیع شده استفاده میکنه ، جدول کاربران من به دلایلی شکسته شده و در پایگاه های دیگر قرار داره ، حالا آیا سیستم Membership از این حالت پشتیبانی میکند ؟؟!

این دوتا سوال مواردی هست که در پروژه های بزرگ ممکنه (وابسته به معماری و نوع پروژه و ..... داره) پیاده سازی بشه و اگر Membership این امکان را نداشته باشه که کلاً قضیه منتفی محسوب میشه .
شاید دوستان بگن این موارد ، موارد استثناء هست و برای همگان پیش نمیاد ،ولی من میگم برای من که پیش اومده پس من استفاده نمیکم ......

نقش ها با RoleId در سیستم Membership ذخیره می شوند، می توانید یک جدول دیگر در دیتابیس اضافه کنید و که کلید اصلی آن همان RoleId باشد و چند فیلد (با هر فرمتی که مایلید)
به جدول فوق اضافه کنید و دسترسی هر نقش را مشخص کنید و با اضافه کردن چند sp و کلاس مدیریت آن راهم کنترل کنید. این جدول جدید به جدول نقش های سیستم Membership وصل می شود و حذف و بروزرسانی هم خودکار انجام می شود.

با توجه به این که اطلاعات Membership با استفاده از Guid (کلید همه جداول) در دیتابیس ذخیره می شوند به نظرم نباید مشکلی در توزیع جداول آن وجود داشته باشد.

[mahdi_farhani]

اگر زمانی خواستید با اوراکل کارکنید اونوقت چی ؟

[Omid.Mafakher]

-------------------------------------