مناسبترین روش تبادل اطلاعات بین دو سرور

[payamka]

سلام
من میخوام بین دو سرور اطلاعات رو رد و بدل کنم،به این صورت که یه فایل روی سرور میزبان قرار میگیره که پاسخگو به درخواست های سرور درخواست کننده باشه،بعد از طریق تابع file_get_contents() نتیجه رو دریافت کنم.
فایل میزبان به یک سری پارامتر نیاز داره که میخوام اونا رو از طریق get ارسال کنم:



file_get_contents('http://example.com/tst.php?s=qqqq');

آیا این روش مناسبه و امنیت داره؟
از چه راهی میتونم مطمئن شم که درخواست از طرف سرور مورد اعتماد بود؟

[2undercover]

فک می کنم استفاده از پروتکل Soap و وب سرویس ها ایده ی بهتری باشه!

[payamka]

مشکل این روش چیه؟
راهی نیست که بشه آدرس سایت درخواست کننده رو پیدا کرد؟

[MMSHFE]

راه برای امن کردن کدها زیاده. مثلاً نام کاربری و رمز عبور رو هم علاوه بر خود پارامتر اصلی دریافت کنید و فقط به کسانی که نام کاربری و رمز عبور درست رو ارسال میکنن جواب بدین و اگه کسی چند بار نام کاربری و رمز عبور رو اشتباه زد، IP رو تا مدت مشخصی Block کنید و دیگه بهش جواب ندین ولی روشهای دیگری هم وجود دارن مثل وب سرویس که دوستمون اشاره کردن که مزیتش اینه که مستقیماً با واردکردن آدرس در مرورگر نمیتونن دسترسی پیدا کنن و باید حتماً از SOAP Client استفاده بشه (البته با REST هم میشه) و روش دیگه که بازهم امنیتش بیشتره، طراحی Socket Server هست تا فقط با Port که خودتون مجاز کردین، بشه بهش وصل شد و اینطوری دیگه حتی امنیت از وب سرویس هم بالاتر میره ولی خوب طبیعتاً افراد کمتری میتونن به اینجور سرویسها وصل بشن چون عمومی و رایج نیست و احتمالاً تعداد کسانی که دانش کافی رو در این زمینه داشته باشن، کمتره. آدرس سایت درخواست کننده به راحتی با ['SERVER['HTTP_REFERER_$ قابل دریافته ولی به همین راحتی هم قابل جعله (توسط ابزارهایی مثل Live HTTP Headers و...) بنابراین زیاد بهشون اعتماد نکنید.

[rezaonline.net]

در تکمیل حرفهای آقای شهرکی بنده پیشنهاد میکنم از soap استفاده کنید .
وحتما آی پی سرور رو بررسی کنید (سرور درخواست کننده ).
ترجیحا ترتیبی بدید که قبلا توی سیستمتون سایتهایی که قرار هست درخواست بفرستن اول آی پی رو ثبت کنن یه جورایی لیست سفید درست کنید ، شبیه وبسرویس بانکها.
یوزر و پسورد فراموش نشه .

[eshpilen]

soap کیلو چند آقا؟
soap پروتکلی بد طراحی شده و بیش از حد پیچیده است.
از راه حلهای ساده تر موجود استفاده کنید؛ چیزی هم کم و کسر نداره.
REST اومد بخاطر همین. چون soap بیش از حد پیچیده و بیش از حد متفاوت و جدید بود و از فناوریها و امکانات موجود استفاده نکرده بود و با بقیهء پروتکل ها و ساختارهای وب سازگاری/هماهنگی کافی نداشت.


مزیتش اینه که مستقیماً با واردکردن آدرس در مرورگر نمیتونن دسترسی پیدا کنن و باید حتماً از SOAP Client استفاده بشه (البته با REST هم میشه) و روش دیگه که بازهم امنیتش بیشتره، طراحی Socket Server هست تا فقط با Port که خودتون مجاز کردین، بشه بهش وصل شدمهندس همه این دلایلی که میگی شباهت زیادی به امنیت از طریق تیرگی دارن؛ تازه شاید یه چیزی درپیت تر از اون باشه!
آدم معمولی در آدرس مرورگر نمیتونه وارد کنه؟! آخه اینم شد دلیل و امنیت و روش حرفه ای؟!
این چیزا همش براحتی قابل فائق آمدن هست. اطلاعاتش هست، ابزارش هست، میشه برنامه نوشت، میشه برنامه براش گیر آورد، میشه تست و کشف کرد. چیز خاصی از امنیت اصولی نداره.
خلاصه راه درست این جنگولک بازیهای الکی و غیرقابل اتکا نیست.

اگر میخواید فقط خودتون یا افراد مجاز بتونن دسترسی پیدا کنن. خب این میشه احراز هویت. از یکی از روشهای احراز هویت استفاده کنید. ساده ترین و متداولترین نوعش پسورده. پسورد باید قوی باشه یا از یک کلید رندوم با آنتروپی کافی استفاده بشه (پیشنهاد من 2 به توان 128 است).

یه درجه دیگه بخواید امن کنید، اگر مهم باشه، اینه که در حین انتقال هم اطلاعات رمزگذاری شده باشن تا حتی یک کسی که روی کانال ارتباطی کنترل/استراق سمع داره هم نتونه اطلاعات رو سرقت یا دستکاری کنه. برای این هم اگر از رمزگذاری متقارن بخواید استفاده کنید (بازهم یکی از ساده ترین و متداولترین - البته درمیان روشهای اصولی!) پیشنهاد من AES CBC 128 + HMAC (http://www.hamidreza-mz.tk/?p=566) است.

حالا بستر انتقال هم میتونه همون HTTP POST باشه. یعنی بعنوان ساده ترین روش اگر کافی باشه.
البته GET هم ممکنه برای بعضی موارد کافی یا حتی لازم باشه (ولی انتقال اطلاعاتی مثل پسورد از این طریق توصیه نمیشه). اینکه میگم لازم بخاطر مسائل caching هست که البته اینم اطلاعات کامل ندارم و باید بررسی و تحقیق بشه (برنامه نویس برنامه نویس باشه خودش تست هم میکنه بالاخره میفهمه).

[eshpilen]

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

[رضا قربانی]

دوستان soap کار ، مگه REST چشه ؟
اینو نگاه کن : یه نمونه از ارسال پارامتر به سایت های پیامکی هست .
می تونی ازشون الگو بگیری
خیلی آسون - شیک - مجلسی ....

در کل عنوان تاپیک به درخواستت نمی خوره.


function SendREST($username,$password, $Source, $Destination, $MsgBody, $Encoding)
{

$URL = "http://www.asanak.ir/webservice/v1rest/sendsms";
$msg = urlencode(trim($MsgBody));
$url = $URL.'?username='.$username.'&password='.$password.'&source='.$Source.'&destination='.$Destination.'&message='. $msg;
$headers[] = 'Accept: text/html';
$headers[] = 'Connection: Keep-Alive';
$headers[] = 'Content-type: application/x-www-form-urlencoded;charset=UTF-8';
$process = curl_init($url);
curl_setopt($process, CURLOPT_HTTPHEADER, $headers);
curl_setopt($process, CURLOPT_HEADER, 0);
curl_setopt($process, CURLOPT_TIMEOUT, 30);
curl_setopt($process, CURLOPT_RETURNTRANSFER, true);
curl_setopt($process, CURLOPT_FOLLOWLOCATION, 1);
if(($return = curl_exec($process)))
{
return $return;
}
}

[rezaonline.net]

@eshpilen (http://barnamenevis.org/member.php?148005-eshpilen) :
برادر من ، شما روحیه مبارزه طلبی خوبی داره :)
هر مشکلی رو با چندین راه حل میشه حل کرد ، شمام بیا راه حل خودت رو بده ، و بگو rest این مزیت ها رو داره .
دیگه چرا میکوبی آدم رو؟
من با جفتشون کار کردم rest مسلما سریعتر هست ، اما برای اینکه ایشون احتمالا اولین بار هست ارتباط بین دو سرور رو انجام میده ، با soap پیاده اش کنه هم براش راحتتر هست هم نتیجه بهتری میگیره :)
حالا شما هی بیا بزن توی سر حرف این و اون .
من میدونم شما از اون آدمهایی هستید همیشه شعار میدید و عملتون پائین .
من تا الان برای سه تا سایت وبسرویس soap رو پیاده کردم که روزانه بالای ده هزار تا درخواست روی اون وبسرویس انجام میشه اما بعید میدونم شما یه سایت با REST پیاده کرده باشید که بصورت کاربردی استفاده بشه توسط عموم .

@رضا قربانی :
آخه سالار ، نوکرتم ، اینجا استارتر اومده ارتباط بین دو سرور رو خواسته ، بهتره تاپیک رو نکنیم مقایسه REST و SOAP که بنده خدا بد جوری گیج میشه :)

[eshpilen]

@eshpilen (http://barnamenevis.org/member.php?148005-eshpilen) :
هر مشکلی رو با چندین راه حل میشه حل کرد ، شمام بیا راه حل خودت رو بده ، و بگو rest این مزیت ها رو داره
من در این مورد خاص راه حلی ارائه نکردم، بلکه دربارهء پاسخهای دیگران که خاص این موضوع نبودن و نسبتا کلی بودن و اشکال داشتن اظهار نظر کردم. براش دلیل و سند کافی هم هست و فکر میکنم بقدر کافی روشن و واضح باشه.
اشارهء من به REST هم بعنوان یک مثال و سرنخ بود تاحدی مثل سند که افرادی که میخوان از قضیه مطمئن بشن و تحقیق بیشتری بکنن رو روشن و هدایت کنه.
دربارهء REST بنده قبلا کلی تحقیق کرده بودم منابع متعددی رو خونده بودم، و تمام حرفهایی که زدم از خودم نبوده بلکه از این منابع و افراد بوده. اینم مقاله ای که در این مورد داده بودم: http://www.hamidreza-mz.tk/?p=627

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


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


من با جفتشون کار کردم rest مسلما سریعتر هست ، اما برای اینکه ایشون احتمالا اولین بار هست ارتباط بین دو سرور رو انجام میده ، با soap پیاده اش کنه هم براش راحتتر هست هم نتیجه بهتری میگیره :)
بنده بحثی روی پرفورمنس و سرعت نکردم. منظورم از پیچیدگی هم پیچیدگی ساختار فنی و قسمت برنامه نویسیش بود.
بنظر من اگر سناریو ساده و اختصاصی ای هست، اصولا نیازی نیست از اینطور سیستمها استفاده بشه و خود طرف هم میتونه هرجور راحتتره بهرصورت راه حل ساده تری رو انتخاب کنه، مثل همون HTTP POST که اشاره کردم. اتفاقا اینکه بتونی از ابزارهای دم دست و راحتی مثل مرورگر برای تست و بررسی یک سیستم استفاده کنی، از نظر فنی یک مزیت است.


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


من تا الان برای سه تا سایت وبسرویس soap رو پیاده کردم که روزانه بالای ده هزار تا درخواست روی اون وبسرویس انجام میشه اما بعید میدونم شما یه سایت با REST پیاده کرده باشید که بصورت کاربردی استفاده بشه توسط عموم .اینا که شما میگی اصلا ربطی به حرفا و بحث من نداره.
شما دربارهء پرفورمنس و کار کردن صحبت میکنید، درحالیکه من دربارهء امنیت اصولی و حرفه ای صحبت کردم و یکسری مسائل جانبی دیگه که بحث روی اونها هم تقریبا در حیطهء تئوری است تا عملی!
اشاره به REST هم همونطور که گفتم فقط یک مثال بود و پاسخ و پیشنهادی برای پرسش استارتر نبود.

[MMSHFE]

Eshpilen جان، 90٪ هکرهای موجود در اینترنت، همین بقول شما جوجه هکرها هستن که با ساده ترین روشها مثل عدم امکان دسترسی ازطریق Browser و... میشه جلوی اونها رو گرفت. 90٪ کسانی که سایت طراحی میکنن هم آماتور هستن و تشریح روشهای پیچیده برای اونها، فقط باعث میشه سردرگم بشن و نتونن کاری که میخوان رو انجام بدن. اون 10٪ هکرهای حرفه ای هم مطمئن باشین سراغ هک کردن سایتهای 10٪ برنامه نویس حرفه ای میرن. بنابراین بهتره روشهایی رو توضیح بدین که ساده تر پیاده سازی شدن. من نگفتم امنیت ازطریق تیرگی (که اگه اشتباه نکنم، تنها واژه فنی هست که مدت یکساله مدام شما توی این انجمن دارین درموردش بحث میکنید)، روش خوبیه و قابل اتکا هست ولی بهرحال جلوی خیلیها رو میگیره و اینکه ازش استفاده نکنیم چون جلوی حرفه ایها رو نمیگیره، منطقی نیست. دزدهای حرفه ای براحتی قفلهای معمولی رو باز میکنن ولی شما باز هم در خونه خودتون رو قفل میکنید تا حداقل اگه دزد به خونه شما زد، یک حرفه ای باشه و دلتون نسوزه که مشکل از سهل انگاری خودتون بوده. درسته REST پیاده سازی راحتتری نسبت به SOAP داره ولی عمومیت و قابلیت اجرا در تقریباً تمام زبانهای برنامه نویسی و دستگاههای مختلف مثل موبایل و... مزیتی هست که REST هنوز بهش نرسیده. ازطرفی Socket Server هم با قابلیت تنظیم پورت و شنود فقط از این طریق و امکان بررسی دقیق IP کلاینت (که اگه جعل بشه، جوابهای سرور براش نمیره)، امنیت بیشتری نسبت به وب سرویسها داره. اینجور مسائل، ارزش بحث کردن نداره و به به حد کافی توی اینترنت سند و مدرک و مثال عملی اجرا شده براش وجود داره که نخوایم وقتمون رو اینجا صرفشون کنیم. حالا شما علاقه مند به صرفاً تحقیق و مطالعه هستین، میتونید درمورد این مباحث تحقیق کنید تا براتون روشن بشه. اینکه شما سند چیزی رو ندیدین (که احتمال میدم بخاطر اینه که بطور جدی هنوز وارد مباحث عملی نشدین)، دلیل بر عدم وجودش نیست. Security through obscurity هم همه جا گفته شده که «کافی نیست» و هیچکس نگفته «لازم نیست».
این حرف شما که میگین خیلی از برنامه نویسان که نمونه کار هم اتفاقاً زیاد دارن، دانش کافی ندارن رو قبول دارم. اما ازطرف دیگه، تعداد کسانی که دانش کافی دارن ولی کار عملی نکردن هم زیاده و این هر دو مورد بده. بقول معروف عالم بی عمل و عامل بی علم هر دو بی فایده است و ضرر میرسونه. یکی نا آگاهانه و یکی دیگه آگاهانه. پیشنهاد میکنم شما هم کم کم حداقل برای خودتون هم که شده (نه بعنوان پروژه برای مشتری) شروع به انجام کارهای عملی و طراحی سایتهای مختلف کنید تا نواقص روشهایی که بطور آکادمیک مطالعه کردین، برای شما مشخص بشه. مثلاً یک تکنیک ممکنه توی لینوکس اونطوری که توی ویندوز جواب میده، کار نکنه و نیاز به کمی Tweak داشته باشه و هیچکدوم از این موارد ریز، بصورت عمده و زیاد جایی گزارش نشده که بخواین با تحقیق بهش برسین و فقط با انجام کارهای عملی کشف و رفع خواهد شد. موفق باشید.

[payamka]

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

[eshpilen]

Eshpilen جان، 90٪ هکرهای موجود در اینترنت، همین بقول شما جوجه هکرها هستن که با ساده ترین روشها مثل عدم امکان دسترسی ازطریق Browser و... میشه جلوی اونها رو گرفت.
همون 10% هم برای خیلی کارها قابل قبول نیست.
وقتی روشهای استاندارد قوی وجود دارن که 99.99% امنیت میدن، چرا روشهای درپیت؟
اصولا روشهای درپیت نباید توسط فردی مثل شما دانشگاه رفته اینطور مطرح بشن. این آموزش غیراصولی و ترویج بیشتر روشهای درپیت و غیرعلمی و گمراه کردن نوآموزان است.
حالا شما میخواید به همین وضع ادامه بدید بدید، ولی بذارید منم کارم رو بکنم.


90٪ کسانی که سایت طراحی میکنن هم آماتور هستناینو میدونم.
حتی همون اول میخواستم بگم چیزهایی که من میگم فکر نمیکنم استارتر اصلا بتونه کامل بفهمه و عملی کنه؛ ولی بهرحال من در سطح بالاتری صحبت خودم رو مطرح میکنم، شاید کسی پیدا شد فهمیدم و استفاده کرد؛ از طرف دیگر بالاخره از جایی باید شروع کرد دیگه! یکی باید باشه بدونه و بگه، کم کم و برای آینده ممکنه کار اصلاح همینطور شروع بشه.


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


اگه اشتباه نکنم، تنها واژه فنی هست که مدت یکساله مدام شما توی این انجمن دارین درموردش بحث میکنیداین اصطلاح (Security through obscurity) کلی هست و گسترهء وسیعی از کارهای عملی رو دربر میگیره (و ظرافت های خاص خودش رو هم داره) و تفکر و اشتباهی هست که اکثریت برنامه نویسان مدام دارن مرتکب میشن. تکرار کردنش بخاطر همینه. مثل شاگردی که مدام یک چیزی رو اشتباه انجام میده و معلم مجبوره مدام نکته و درسش رو تکرار کنه (یا بهش اشاره کنه). شاید مشکل از شاگرد است، نه معلم. نه؟
اطمینان زیادی دارم که خیلی ها از این اصطلاح و معناش هنوز هم اطلاع درست و درک کامل و دقیقی ندارن، بخاطر همین مدام با برخورد به موارد و مثالهاش سعی میکنم اون رو مطرح و روشن کنم.
شاید 99% کارهای برنامه نویسی در ایران، و حتی شاید بیشتر، از اینطور ضعفها دارن.
البته چیزهایی که بنده میگم در سطح علمی و آکادمیک بیشتر فهمیده میشن و نیاز هستن، و بیشتر برای کارهای حرفه ای و علمی و قوی مثلا درحد مراکز نظامی و امنیتی و خلاصه کارهای حساس، ولی در کارهای عادی هم کم پیش نمیاد که همین مسائل مشکل ایجاد کنن و از طرف دیگر این امکانات به رایگان و راحتی در اختیار همگان هست پس چرا استفاده نکنیم؟ راه اصولی اینه که یاد گرفت، یه مدت زحمت کشید، بعد از روشهای اصولی استفاده کرد. اینطوری میتونیم بگیم برنامه نویس واقعی هستیم و هرچیزی رو که برای کارمون ممکنه لازم بشه واقعا بلد هستیم، و در موارد خاص هم صلاحیت کافی داشته باشیم. البته اینم بگم که تاجاییکه فهمیدم در کشورهای دیگه مثل آمریکا، نقش متخصص امنیت و رمزنگاری رو جداگانه دارن؛ یعنی مثل تفاوت توسعه دهنده (دولوپر) و طراح (دیزاینر).


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


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

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


حالا شما علاقه مند به صرفاً تحقیق و مطالعه هستین، میتونید درمورد این مباحث تحقیق کنید تا براتون روشن بشه. اینکه شما سند چیزی رو ندیدین (که احتمال میدم بخاطر اینه که بطور جدی هنوز وارد مباحث عملی نشدین)، دلیل بر عدم وجودش نیست. Security through obscurity هم همه جا گفته شده که «کافی نیست» و هیچکس نگفته «لازم نیست».چرا اینا که گفتی همه رو میدونم.
در بالاتر توضیح کافی دادم.
ضمنا روشهایی که بنده میگم همین الان اساس زندگی و امنیت اینترنت و فضای دیجیتال شما بر اونها استواره و بقدر کافی عملی هستن و محک خوردن. اگر اینها نبودن که دنیا اینطور هم نمیچرخید! فکر میکنید با این روشهای من درآوردی دوتا جوجه برنامه نویس میشد دنیا رو اداره کرد؟ واقعیت اینه که لایه های زیربنایی وجود دارن که با اصول و علم حرفه ای هستن و در بستر وجود و فعالیت بقیهء افراد هم نقش مهمی دارن، ولی خیلی ها حتی همین مطلب رو نمیدونن/درک نمیکنن.


این حرف شما که میگین خیلی از برنامه نویسان که نمونه کار هم اتفاقاً زیاد دارن، دانش کافی ندارن رو قبول دارم. اما ازطرف دیگه، تعداد کسانی که دانش کافی دارن ولی کار عملی نکردن هم زیاده و این هر دو مورد بده. بقول معروف عالم بی عمل و عامل بی علم هر دو بی فایده است و ضرر میرسونه. یکی نا آگاهانه و یکی دیگه آگاهانه. پیشنهاد میکنم شما هم کم کم حداقل برای خودتون هم که شده (نه بعنوان پروژه برای مشتری) شروع به انجام کارهای عملی و طراحی سایتهای مختلف کنید تا نواقص روشهایی که بطور آکادمیک مطالعه کردین، برای شما مشخص بشه. بهرحال حیطهء تئوری و عملی تاحدی جداست و در بعضی حیطه ها میشه کاملا جدا کرد.
همیشه لزومی نداره که کسی که تئوری میخونه و کار میکنه عملی هم کار کنه. بستگی به فیلد و هدف داره.
شما میتونید از کسی که استاد تئوریک فیلد خاصی هست هم خیلی چیزها یاد بگیرید که برای کار عملیتون مفید یا حتی لازمه. فکر نمیکنم نیازی به اثبات این امر باشه، چون تمام تاریخ و علم و فناوری بشر داستانش همینه. یک عده فقط یا بیشتر روی تئوری کار کردن و یک عده روی عملی (که خیلی وقتا استفادهء عملی از همون تئوری ها بوده) و البته یک عده هم روی هردو (ولی روی هردو کار کردن طبیعتا دشوارتره و نیاز به وقت و انرژی آزاد زیادی داره و همیشه و برای همه ممکن نیست تا در هردو به حد کمال برسن). هیچکدام از این دوتا نمیتونن جایگزین دیگری بشن، و برای کار کردن و مرجع بودن روی یک بخش همیشه لزومی نیست که در وادی دیگر هم همونقدر کار کنید.
نقش دانشمند با مهندس فرق میکنه.
تازه بنده میتونم بگم که در این حیطه (رایانه و فناوری اطلاعات و برنامه نویسی)، تئوری و عمل خیلی به هم نزدیک هستن و گاهی تقریبا یکی. بخاطر همین بنده در خیلی موارد میتونم بصورت تئوریک و ذهنی حتی از عملی و تجربی هم بهتر مسائل رو پیشبینی و درک کنم و اطمینان زیادی دارم که در عمل هم با مشکل و اشتباه جدی ای مواجه نمیشم. شما وقتی یک الگوریتم و اصول علمی چیزی رو قشنگ درک کنی، میبینی که عمل فقط عبارت است از جنبهء فیزیکی بخشیدن به اون (البته با کمی مسائل تجربی و موارد پیشبینی نشده عملی در بعضی موارد). خیلی از سوالاتی هم که در این فروم مطرح میشن برای بنده پیش پا افتاده هستن و واقعا هیچ مشکلی در طراحی و پیاده سازی اونا نمیبینم برای خودم (فقط نیاز به وقت و انرژی و فکر آزاد کافی داره)، چون بیشتر به دانش و قدرت ذهنی برمیگردن تا تجربهء عملی.
فیلدی هم که بنده درش تخصص دارم و بیشتر درش اظهار نظر میکنم، امنیت و رمزنگاری است که از همون فیلدهایی هستند که نقش تئوری در اونها بسیار زیاده (در رمزنگاری تا 90% و بیشتر میرسه). کسی که بتونه تئوری اینها رو یاد بگیره و بهش مسلط بشه، عمل براش نباید مشکل باشه، چون یاد گرفتن و درک تئوریش کار دشوارتریه.

حالا شما میتونید از بنده چیزی یاد بگیرید (البته اگر بتونید)، و میتونید هم بدون دانش و صلاحیت تئوریک کافی بگید چون کار عملی ندارم پس هرچی میگم بی اعتباره و نادیده بگیرید یا بگید بهرحال گفتن و بحث این حرفا بیهوده است.

[eshpilen]

وقتی ما میگیم از «امنیت از طریق تیرگی» بعنوان اساس امنیت سیستم استفاده نکنید، 90% برنامه هایی که تاحالا در ایران نوشته شدن از دور خارج میشن.
حالا روی درصدش اصرار ندارم و نمیخوام اغراق کرده باشم، ولی میدونم که خیلی بالاست؛ شاید مقداری کمتر از 90%، و شاید هم بیشتر.

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

واقعا فکر میکنید از برنامه نویسانی که در همین فروم میان، چندتاشون میتونن امنیت یک برنامهء واقعی رو بدون استفاده از امنیت از طریق تیرگی تامین کنن؟
من میگم حتی در درک این اصطلاح و علتش هم در قدم اول خیلی ها هنوز مشکل دارن، چه برسه به بعدش. بعدش نیاز به یادگیری روشهای اصولی و استانداردهای علمیش داره و کار و زمان زیادی میبره.
حتی فکر میکنم این اصطلاح قبل از اینکه بنده مطرحش کنم در ایران ناشناخته بود! باور کنید!! چون خودم شخصا سالها در اینترنت اثری از این اصطلاح در جامعهء فارسی زبانان ندیده بودم و هیچکس بهش اشاره ای، یا حداقل اشارهء واضح و مستقیمی، نمیکرد.
شاید بنده اولین کسی بوده باشم که این اصل رو در ایران به شکل روشن و کامل و آکادمیکش مطرح کردم (بنابراین بهم میشه گفت پدر علم امنیت ایران :قهقهه:).
درحالیکه این اصطلاح یک اصل زیربنایی در امنیت و رمزنگاری علمی مدرن امروزه است.
پرداختن به امنیت در برنامه نویسی بدون اطلاع و بکارگیری این اصول، مثل اینه که بخواید یک ساختمان رو بدون فرمولها و محاسبات ریاضی بسازید. بله شما میتونید ساختمانهای معمولی و غیربزرگ رو اینطور بسازید (البته حتی با این وجود، مواردی از فروریختن و فاجعه هم در این بین رخ خواهد داد) ولی آیا واقعا میشه و عاقلانه است که برجهای بزرگ و آسمان خراشها رو هم بدون این فرمولها و محاسبات علمی و ریاضی طراحی کرد و ساخت؟ اگر امروز ساختمان چیزیش نشه ولی فردا یک زلزلهء 6 ریشتر بیاد، شما چطور میتونید از مقاومت کافی اون ساختمان مطمئن باشید؟ واقعا چقدر چطور میشه مطمئن بود؟ فقط بر اساس تجربه؟ وقتی فرمول و محاسباتش وجود دارن، آیا عاقلانه است که فقط به تجربه اتکا کنیم؟ بعدم میشه واقعا همه چیز و همه موارد ممکن رو تجربه کرد؟

تمام چیزی که بنده قبلا راجع به امنیت و رمزنگاری در اینترنت فارسی زبانان میدیدم 99% مربوط به هکرها و ترفندها و روشهای اونها میشد، و اثری از روش ها و اصول آکادمیک و ارجاع به فرد و منبعی از این نوع دیده نمیشد. حتی الانش هم خیلی ها همینطور فکر میکنن.
اینکه شما فکر کنید هکرها و دانش و روش هکری، تمام یا بخش کافی و یا حتی بخش اعظم امنیت و رمزنگاری است، جز کمبود سواد رو نمیرسونه.

اگر میخواید فقط برنامهء دیتابیسی و برنامه های تجاری و کلیشه ای رو بنویسید و نهایت با یخورده خلاقیت و تنوع و جنگولک بازی، و فقط مطرح شدن مسائل ضروری اینا رو مجاز/مفید میدونید، خب پس حرفای من بیهوده است.
ولی اگر میخواید بدونید چرا بخش اعظم علم و فناوری مدرن در غرب تولید میشه، چرا خیلی برنامه های خاص اونا رو ما تاحالا ننوشتیم و نمیتونیم درست و حسابی از پسش بربیایم، اونوقت باید به تئوری و علم و اصول واقعی هم احترام بذارید و برنامه نویسی رو به این شکل یاد بگیرید، نه اینکه تا یه Hello world یاد گرفتید شروع کنید کدنوشتن و بخواید صرفا از راه تجربی همه چیز رو یاد بگیرید.

[eshpilen]

ضمنا اینکه بنده کار عملی خیلی کم دارم دلایلش اینها بوده:

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

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

- علاقه و انگیزه ای برای نوشتن همینطوری برنامه ندارم و باید حتما علتی غیر از سرگرمی و خودنمایی و غیره درش باشه تا بهش بپردازم. یعنی ارزشش رو داشته باشه. برنامه هایی هم که نمونه هاشون در دسترس همگان هست (بصورت رایگان) دلیلی نمیبینم بخوام بنویسم، و ترجیح میدم بجاش مطالعه کنم و چیزهای جدید یاد بگیرم.

- کلا هم همیشه فکر میکردم که فرصت برای مطالعه و یادگیری تئوریک هست که در نوجوانی و جوانی مهمه و باید قاپیدش!
چون فکر میکردم بعدها با وجود شغل و وظایف رسمی و دغدغهء درآمد (و اونایی که ازدواج میکنن، بعلاوه دغدغه های خانواده) و غیره، وقت و انرژی و فکر آزاد چندانی برای مطالعه و یادگیری نمیذاره، اما کار عملی که بهرحال توی کار بعنوان درآمد و وظایف همیشه هست.
احتمالا فکرم درست هم بوده. چون الان حتی خودم هم حتی با شرایط و پشتوانه و فرصت خوبی که داشتم، دیگه مثل سابق وقت و انرژی ندارم که مثلا بشینم اون کتابهایی رو که چند سال پیش خوندم کامل و دقیق بخونم.
الان مثلا کسانی که دارن کار تجاری میکنن کی میخوان دیگه این وقت رو پیدا کنن که مطالعه و تحقیق کنن و دانش پایهء خودشون رو کامل کنن؟ میتونن یک کتاب رو 3 ماه روزی 3 ساعت بخونن؟ میتونن بعدش یه کتاب دیگه انتخاب کنن؟

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

[rezaonline.net]

@ eshpilen : من میدونم شما آدم با معلومات بالا هستید و براتون احترام قائلم ، اما متاسفانه هنوز یاد نگرفتید هر سخن جایی و هر نکته مکانی دارد .
این دوستمون یه راه حل میخواد ، باور کنید دارید تاپیکش رو خراب میکنید ، یه خورده خودتون رو جای شخص سوال کننده بذارید ، هر کسی در یک سطح قرار داده و برای ارتقای سطحش باید پله پله بیاد بالا ، نه اینکه یه هویی هلش بدید بالا .
الان سوال دوستمون چی بوده ؟

مناسبترین روش تبادل اطلاعات بین دو سرور
و جواب آخر شما

گر میخواید فقط برنامهء دیتابیسی و برنامه های تجاری و کلیشه ای رو بنویسید و نهایت با یخورده خلاقیت و تنوع و جنگولک بازی، و فقط مطرح شدن مسائل ضروری اینا رو مجاز/مفید میدونید، خب پس حرفای من بیهوده است.
ولی اگر میخواید بدونید چرا بخش اعظم علم و فناوری مدرن در غرب تولید میشه، چرا خیلی برنامه های خاص اونا رو ما تاحالا ننوشتیم و نمیتونیم درست و حسابی از پسش بربیایم، اونوقت باید به تئوری و علم و اصول واقعی هم احترام بذارید و برنامه نویسی رو به این شکل یاد بگیرید، نه اینکه تا یه Hello world یاد گرفتید شروع کنید کدنوشتن و بخواید صرفا از راه تجربی همه چیز رو یاد بگیرید.

:لبخندساده:

بگذریم .


خیلی ممنون از همه دوستان،سناریوی من اینه:
هر کسی که بخواد میتونه ارتباط رو بین سرور من و سرور خودش برقرار کنه،برای این کار یک فایل که به درخواست های سرور من پاسخ میده رو روی سرور خودش آپلود میکنه.پس نحوه کار اون فایل مشخصه چون سورسش برای همه در دسترسه
به خاطر همین باید امنیت از جای دیگه تامین بشه،برای این کار چند عمل مختلف انجام میشه.یکی مسیر و اسم فایل که آپلود شده میتونه تغییر کنه و عمومی نشه و فقط طرفین ارتباط ازش آگاه باشن.کار دیگه آی دی و پسورد اختصاصی برای دسترسی به هر کدوم از میزبان ها تعلق میگیره که قاعدتا بین طرفین رابطه محرمانه میمونه.ولی این آی دی و پسورد به صورت plain توی صفحه آپلود شده ذخیره میشه.
نظر شما چیه؟
اون فایلی که شما روی سرورتون دارید صرفا میشه یک فایل wsdl . مشکلی برای علنی شدن نداره چون با صرفا دونستن اون فایل کسی نمیتونه اطلاعات بگیره مثل بانک پارسیان
https://www.pec24.com/pecpaymentgateway/eshopservice.asmx?wsdl
حالا شما میاید یک متد تعریف میکنید که پارامترهایی بگیره که میتونید یوزر و پسورد رو جز همین پارامترها بذارید یا نه از http auth هم میتونید استفاده کنید .
http://en.wikipedia.org/wiki/Basic_access_authentication
http://php.net/manual/en/features.http-auth.php

موارد رعایت امنیتی پسورد هم که بلدید ، ذخیره بصورت هش و ...

[eshpilen]

این دوستمون یه راه حل میخواد ، باور کنید دارید تاپیکش رو خراب میکنید ، یه خورده خودتون رو جای شخص سوال کننده بذارید ، هر کسی در یک سطح قرار داده و برای ارتقای سطحش باید پله پله بیاد بالا ، نه اینکه یه هویی هلش بدید بالا .
بابا از این تاپیک های با سوالات دوزاری که هر بچه ای داره برنامه سرهم میکنه و توی مسائل اولیش هم مشکل داره که تاحالا زیاد بوده. محتوی و نتیجهء خاصی هم در هیچکدام ندیدم تاحالا که اونقدری ارزش بده به تاپیک. اغلب چند جواب کلی و مبهم و کوتاه هست و بحثی نیست که خیلی ریشه دار و دقیق و کامل و طولانی بخواد باشه.
من اصلا با استارتر کاری ندارم چون همونطور که گفتم از اول کاری نداشتم و میدونم کسی که توی این مسائل میاد کمک و راهنمایی میخواد نمیتونه چیزهایی رو که بنده میگم استفاده کنه.
استارتر میتونه پستهای منو نخونه. کار مشکلیه؟
کسانی هم اینطور سوالات رو جواب میدن اکثرا باز جز یکسری کلی گویی و مبهم گویی اونم بصورت روی هوا و بدون دونستن جزییات و نیازهای واقعی مخاطب چیز دیگه ای بیان نمیکنن. منکه شک دارم از همین جوابها هم پرسشگر بتونه استفادهء زیادی بکنه :متفکر:
یه سرچ هم میزد طرف فکر کنم در این فروم و جاهای دیگر اینترنت سوالات مشابه این زیاد هست با کلی جواب های متنوع و سلیقه ای و مخلفات.

[eshpilen]

کسی که در این حده، بیشتر براش لقمه جویده و کد و مثال کامل کاربرد داره تا این حرفهای قلمبه سلمبه که من و شما میزنیم.
اون کار کد کامل گذاشتن و لقمه جویدن هم که کار ارزشمند و مفیدی نیست. شما دوست داری انجام بده. آقای شهرکی هم قبلا از اینطور کارها میکرد. ولی حاصل این کارها چیه؟ یه عده میان بدون سواد و پایه و صلاحیت و یادگیری اصولی یه چیزایی سرهم میکنن. بعدم میگید چرا برنامه نویسی اینقدر بی ارزش شده اینقدر دستمزدها پایینه و غیره.
بهرحال اینا همش حاصل همین یادگیری های بقول شما تجربی (و درواقع ماستکی!) هست.
طرف از تئوری هیچی بلد نیست میخواد شروع کنه با کدزدن و برنامه نوشتن برنامه نویس بشه، ولی از اون طرف میخواد کار جدی و تجاری بکنه و پول هم بگیره!!

[MMSHFE]

بابا از این تاپیک های با سوالات دوزاری که هر بچه ای داره برنامه سرهم میکنه و توی مسائل اولیش هم مشکل داره که تاحالا زیاد بوده. محتوی و نتیجهء خاصی هم در هیچکدام ندیدم تاحالا که اونقدری ارزش بده به تاپیک. اغلب چند جواب کلی و مبهم و کوتاه هست و بحثی نیست که خیلی ریشه دار و دقیق و کامل و طولانی بخواد باشه.
اغلب مشکلات کاربران، در همین حد هست و اگه بنظر شما این تاپیک فاقد بار علمی مناسب هست، بهتره بدون اهانت، یک تاپیک جداگانه ایجاد کنید و اونجا حرفهای تخصصی خودتون رو مطرح کنید.

من اصلا با استارتر کاری ندارم چون همونطور که گفتم از اول کاری نداشتم و میدونم کسی که توی این مسائل میاد کمک و راهنمایی میخواد نمیتونه چیزهایی رو که بنده میگم استفاده کنه.
استارتر میتونه پستهای منو نخونه. کار مشکلیه؟
این مسئله مصداق Off Topic هست که مخالف قوانینه و همونطور که گفتم، اگه به استارتر و موضوع تاپیک کاری ندارین، لطفاً تاپیک جداگانه ایجاد کنید، درغیر اینصورت مطابق قوانین برخورد خواهد شد.

کسانی هم اینطور سوالات رو جواب میدن اکثرا باز جز یکسری کلی گویی و مبهم گویی اونم بصورت روی هوا و بدون دونستن جزییات و نیازهای واقعی مخاطب چیز دیگه ای بیان نمیکنن. منکه شک دارم از همین جوابها هم پرسشگر بتونه استفادهء زیادی بکنه :متفکر:
یه سرچ هم میزد طرف فکر کنم در این فروم و جاهای دیگر اینترنت سوالات مشابه این زیاد هست با کلی جواب های متنوع و سلیقه ای و مخلفات.
خاصیت فاروم اینه که همه جور سؤال و جواب توش مطرح میشه، منتها جوابها باید مرتبط با موضوع سؤال باشه و قصدشون، رفع مشکل باشه نه اینکه به قول شما به استارتر کاری نداشته باشیم و موضوع تاپیک برامون مهم نباشه. نه شما، نه من و نه هیچ کس دیگری حق نداره یکنفر رو محدود کنه بگه حق نداری سؤال ساده یا غیر تخصصی (اونهم ازنظر شخص خودمون) بپرسی. اینکه توی اینترنت زیاد پیدا میشه هم دلیل نمیشه کسی سؤالش رو نپرسه. شاید اونجاها جواب مناسبی که بدرد استارتر بخوره وجود نداشته یا شاید اصلاً جستجو نکرده باشه ولی بهرحال اگه اینجا جواب مناسبی داده شد، اونوقت این تاپیک هم میشه یک منبع برای کسانی که بعد از این میخوان جستجو کنن.

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

بهرحال اینا همش حاصل همین یادگیری های بقول شما تجربی (و درواقع ماستکی!) هست.
طرف از تئوری هیچی بلد نیست میخواد شروع کنه با کدزدن و برنامه نوشتن برنامه نویس بشه، ولی از اون طرف میخواد کار جدی و تجاری بکنه و پول هم بگیره!!
اگه قرار باشه همه مثل شما تئوری بخونن و همه مستندات رو مطالعه کنن، دیگه عمری برای پیاده سازی این دانش باقی نمیمونه. تا وقتی هم که در عمل درگیر کار نشین، خیلی چیزها که در هیچ سندی مکتوب نشده رو تجربه و درک نخواهید کرد. این رو هم مطمئن باشین کسی که داره روی ارتباط بین دو سرور کار میکنه، قطعاً در مباحث تئوری، یه چیزهایی بلده و اینطور نیست که کلاً فاقد دانش پایه باشه. حالا شاید یه جای خاصی کارش گیر کنه که با راهنمایی دیگران رفع میشه. حتی اگه بنظر برخی، اون روش اشتباه باشه، در دنیای واقعی و عملی، تا وقتی که مشکل خاصی رو متوجه Application نکنه، استفاده از اون اشکال جدی ایجاد نمیکنه. برای مثال، شما که اینقدر دانش تئوری قوی دارین، میشه مثال بزنید کدوم سرور بوده تا حالا که با SOAP پیاده شده باشه و در ترافیک بالای بازدید به مشکل برخورده باشه؟ یا از REST چطور میشه در همه Platformها استفاده کرد؟ یا حتی سند قطعی و علمی بیارین که گفته شده «اصلاً نباید از امنیت ازطریق تیرگی استفاده کرد»؟ من هم قبول دارم تکیه کردن به STO اشتباهه ولی اگه تکیه گاه ما این روش نباشه، بعنوان یک ابزار در کنار سایر روشها، ابداً اشکالی نداره که ازش استفاده کنیم. درسته فقط با تجربه نمیشه جلو رفت ولی فقط تحقیق و مطالعه هم کافی نیست و خیلی چیزها هست که تا حالا تجربه نشده و درنتیجه سند علمی هم برای رفع و رجوعش وجود نداره. مباحثی مثل ارتباط دو یا چند سرور هم از همین دست مسائله و باید حتماً تجربه عملی در کار با اونها داشته باشین تا بدونید چه مشکلاتی ممکنه پیش بیاد. حالا REST داره مقادیر رو به صفحه با کمک CURL یا سایر روشها ارسال میکنه، باعث میشه بگیم SOAP کارآیی نداره؟ فکر کنم از اونجایی که چندجا دیدین گفتن REST جدیدتر و مدرن تره و سازگاری بیشتری با استانداردهای جدید داره، دیگه درمورد SOAP تحقیق بیشتری نکردین که ببینید چه مزایایی داره. مطمئن باشید اگه REST بطور مطلق برتر از SOAP بود، 95٪ درگاههای پرداخت دنیا بجای SOAP از REST استفاده میکردن. اون 5٪ هم که دارن با REST کار میکنن، SOAP رو هم دارن و REST رو بعنوان یک Option اضافه معرفی کردن.

[eshpilen]

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


نه شما، نه من و نه هیچ کس دیگری حق نداره یکنفر رو محدود کنه بگه حق نداری سؤال ساده یا غیر تخصصی (اونهم ازنظر شخص خودمون) بپرسیجایی نگفتم حق نداره بپرسه.
بپرسه. میتونید جواب هم بدید و بخونه. حالا منم این وسط حرف خودم رو میزنم. یعنی طرف اینقدر خنگه یا مسئله اونقدر پیچیده و مبهمه که حرف زدن من باعث بشه طرف جوابش رو نگیره که قبلش میتونست بگیره؟
چیزی که بنده میبینم اینه که یکسری کلی گویی و مبهم گویی شده و همچنین تفکر و روشهای غلطی مستقیما یا غیرمستقیما بیان شده. در اینها محتوا و جواب بدردبخور چندانی نیست که حالا با بحث من بخواد منحرف بشه و استارتر از این گنجینه محروم بشه!
شما میگید SOAP ، REST و چندتا حرف کلی و اینکه مثلا استفاده کردید و خوب بوده و اینها. بنظر شما این جوابی هست که استارتر بهش نیاز داره؟ یعنی مشکلش همین بود که شما اسم SOAP و REST رو بیارید حل بشه؟ هرکسی که دانش و توانایی برنامه نویسی حداقلی داشته باشه میتونه براحتی اسم و کلیت اینها رو بفهمه، و نیازی به پرسش و شنیدن از من و شما نیست. تازه اصلا در اکثر موارد نباید نیازی به این اسمها باشه، چون با روشهای ساده تر و پایه ای تر هم میشه کار مورد نظر رو انجام داد. تمام اینترنت نقل و انتقال اطلاعاته و این ساده ترین چیزها و امکانات همه جایی هست و نت و زبانهای برنامه نویسی ازش پر هستن. کسی که برنامه نویسی وب میکنه نباید واسه همچین چیزهای پیش پا افتاده ای مشکل داشته باشه. بلکه مشکل در دانش پایه و قدرت طراحی الگوریتم هست بیشتر. یا بعضی موارد مثل همون امنیت اصولی که اونم بنده درستش رو گفتم و نه شما.


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


این رو هم مطمئن باشین کسی که داره روی ارتباط بین دو سرور کار میکنه، قطعاً در مباحث تئوری، یه چیزهایی بلده و اینطور نیست که کلاً فاقد دانش پایه باشهاینم شد دلیل؟ :متفکر:
مثلا دیروز کارفرماش اومده گفته میخوایم برنامه/سایتی که برامون نوشتی فلان کار رو هم انجام بده فلان چیز اونطوری باشه، که در نتیجه نیاز به ارتباط بین دو سرور پیش آمده. این دلیل نمیشه که خودش چیز زیادی بلد باشه!


میشه مثال بزنید کدوم سرور بوده تا حالا که با SOAP پیاده شده باشه و در ترافیک بالای بازدید به مشکل برخورده باشه؟ یا از REST چطور میشه در همه Platformها استفاده کرد؟این چیزا که گفتید به بحث بنده هیچ ربطی نداره. من فقط درمورد امنیت و تفکر و روشهای غیراصولی که شما شاید ناخواسته آموزش دادید و ترویج کردید صحبت کردم. کاری به بقیهء مسائل مثل پرفورمنس نداشتم. اصلا چیزهایی که من گفتم منافاتی با اینها ندارن و میتونن در هرکدام پیاده بشن. موضوع این بود که ساختار و محدودیت های خود این فناوریها رو که هیچ ارتباط مستقیم و عمدی و قوی ای به امنیت ندارن بعنوان راهکار امنیت مطرح کردید.
من میگم اون چیزی که شما گفتید درست نیست و امنیت نیست، بلکه توهم امنیت است و تکیه به شانس و حدسهای غیرقابل اثبات و اتکا.
میخواید SOAP استفاده کنید، میخواید REST استفاده کنید، بهرحال برای امنیتش باید روشهای اصولی رو رعایت کنید و اینها خودشون به تنهایی هیچ امنیت واقعی نمیدن از دید تخصصی.
اینم که گفتم SOAP بد طراحی شده بخاطر اینکه بعضیا ظاهرا گول ظاهرش رو میخورن فکر میکنن چون پیچیده و جدید بنظر میاد یعنی بهتره. این یه مسئلهء جانبی بود.
SOAP هم کار انتقال اطلاعات رو انجام میده، ولی در خیلی موارد که SOAP برای اونا هم درنظر گرفته شده بود و استفاده شد و میشه، درواقع به SOAP نیازی نیست و REST چون با بقیهء ساختار و استانداردهای وب هماهنگی و ارتباط بیشتری داره میتونه بهتر هم باشه. بهرحال من در این مورد خاص بحث و اصرار بیشتری ندارم. میخواید هرکدام رو که فکر میکنید بهتره استفاده کنید. از HTTP POST و راهکارهای خصوصی میشه استفاده کرد تا این فناوریها یا پروتکل ها و استانداردها. همونطور که گفتم بسته به جزییات و نیازهای دقیق هر مورد داره و نمیشه همینطور با همین اطلاعات کلی و مبهم و محدود حرف قاطعی در این زمینه زد.


سند قطعی و علمی بیارین که گفته شده «اصلاً نباید از امنیت ازطریق تیرگی استفاده کرد»؟ من هم قبول دارم تکیه کردن به STO اشتباهه ولی اگه تکیه گاه ما این روش نباشه، بعنوان یک ابزار در کنار سایر روشها، ابداً اشکالی نداره که ازش استفاده کنیم.سند برای ادعایی که نکردم؟
تا اینجا بقدر کافی توضیح دادم که بحث این نبوده، ولی شما باز تکرارش میکنید.
من جایی نگفتم از امنیت از طریق تیرگی اصلا نباید استفاده بشه، بلکه چیزی که گفتم این بود که تاحدممکن بعنوان تنها راهکار یا اساس امنیت سیستم نباید استفاده بشه. در عمل هم نیاز به استفاده ازش، اگر از روشهای علمی و اصولی امنیت استفاده بشه، خیلی کمتر از اونیه که شما فکر میکنید یا حداقل حرفاتون اینطور القا میکنه.
کاری که اکثر برنامه نویسان دارن میکنن این نیست که امنیت از طریق تیرگی رو در کنار روشهای اصولی و علمی استفاده کنن، بلکه اکثرا امنیت از طریق تیرگی بعنوان هستهء امنیت یا بخش بیش از حد اساسی و مهمی از امنیت سیستم هست براشون. اینم بخاطر ضعف دانش لازم در طراحی و پیاده سازی روشهای اصولی و استانداردش هست، و البته شاید تنبلی هم یک عاملش باشه، چون روشهای اصولی و استاندارد و بی نقص میتونن حجم و پیچیدگی برنامه نویسی رو چند برابر کنن.
امنیت اصولی یعنی باید اینطور باشه که شما اگر امنیت از طریق تیرگی رو ازش حذف کنید، امنیت سیستم هنوز هم درحد استاندارد و حداکثر ممکن باقی بمونه. درحالیکه اکثر برنامه ها اینطور نیستن و اگر سورس و جزییاتش دست هکر بیفته (یا خودش با حدس و مهندسی معکوس و غیره کشف کنه)، امنیت سیستم بیش از حد پایین میاد.
بخاطر همین وقتی از روشهای اصولی بی نقص استفاده بشه، استفاده از امنیت از طریق تیرگی در خیلی موارد اصلا ضرورت چندانی نداره و صرف نمیکنه، چون میزان امنیتی که اضافه میکنه آنچنان زیاد و ضروری نیست و در مقابل پیچیدگی و هزینه های خودش رو داره.
برنامه های بازمتن بطور مثال، اکثرشون بدون امنیت از طریق تیرگی هستن. آیا لینوکس امنیت کافی نداره؟ و این همه برنامه های دیگر بازمتن؟
حالا شما خیلی اصرار یا شرایط خاصی دارید میتونید امنیت از طریق تیرگی رو هم به سیستم خودتون اضافه کنید و یک لایه و محکم کاری امنیتی بهش اضافه کنید. البته در اینکه امنیت اضافه شده چقدر باشه خب تشخیصش کار راحتی نیست و زیاد اصول و فرمول مشخصی نداره (بنده ندیدم و به ذهنم نمیرسه)، و احتمالا در بیشتر موارد میزان زیادی نیست درکل. حتی خود این پیچیدگی افزوده به برنامه و نگهداری و تست و توسعهء اون و انحراف انرژی و تمرکز برنامه نویس میتونه منجر به باگ و ضعف در زمینهء امنیت هم بشه که شاید از اون امنیتی هم که میخواستیم اضافه کنیم بیشتر ضرر بزنه.



اگه REST بطور مطلق برتر از SOAP بود، 95٪ درگاههای پرداخت دنیا بجای SOAP از REST استفاده میکردن. اون 5٪ هم که دارن با REST کار میکنن، SOAP رو هم دارن و REST رو بعنوان یک Option اضافه معرفی کردن. نه شاید واقعا در بعضی یا خیلی موارد هم SOAP مناسبتر از REST باشه؛ من در این حد دیگه تجربه و تحقیق نداشتم که این رو نفی کنم. اما در اینکه SOAP یک مقدار بصورت اشتباه و با دید و روش اشتباهی طراحی شد و با بقیهء استانداردها و ساختار وب هماهنگی و سازگاری خوبی نداشت و در خیلی موارد تکرار امکاناتی که قبلا به شکل دیگری موجود بودن بوده، منبع خوندم براش اونم چند منبع و افرادی که فکر میکنم سواد و اعتبارشون بقدر کافی بوده باشه. منجمله خود کسی که REST رو طراحی کرد و به علتهاش اشاره کرده. اگر این فرد یک فرد عادی بود و استدلالش درست نبود، کسی بیخود برای چی دوباره یه چیزی به اسم REST رو برای کاربردهای مشابهی باید درست میکرد؟ بیکار بودن؟
اینم که SOAP گسترده تر از REST استفاده میشه و اکثرا REST در کنار SOAP هست خب میتونه تاحد زیادی بخاطر همون سابقهء بیشترش باشه و اینکه تا REST بیاد اختراع و مطرح بشه و جا بیفته، SOAP در بین خیلی برنامه نویسان و کاربردها جا افتاده بود و برنامه ها و ابزارهای زیادی در همه جا بطور گسترده براش ساخته و تعبیه شده بود. این جاافتادگی و عادت خودش کم عاملی نیست، هزینهء سویچ هست، هزینهء یادگیری هست، هزینهء برنامه نویسی مجدد هست، نیاز به Backward compatibility هست، اینرسی اجتماعی هست.