برای یه روز هم که شده، بدون خودرو مسافرت کنید.
به تمام مترو و اتوبوس‌سوارها تبریک می‌گم.

#event #note
@amiria703_channel

میزلینوکسی GNOME 47 “Denver” منتشر شد

جزئیات به زودی پست میکنم

نویسنده: حسین سیلانی
منبع : کانال لینوکسی: لینوکس تی ان تی
@linuxtnt

حمایت -donate
https://zarinp.al/learninghive.ir

💎 هدر Authentication چیه و چطوری ازش استفاده کنیم؟ 💎

امروز می‌خوایم درباره هدر Authentication صحبت کنیم، چیزی که اپلیکیشن‌های وب برای احراز هویت (Authentication) استفاده می‌کنن و توی دنیای APIها خیلی کاربرد داره 😎.

هدر Authentication چیه؟ 🤔
هدر Authentication یه هدر HTTP هست که اطلاعات لازم برای احراز هویت کاربر رو توی درخواست‌ها به سرور می‌فرسته. این هدر کمک می‌کنه که سرور بفهمه چه کسی داره درخواست رو می‌فرسته و اینکه اجازه دسترسی به منابع مختلف رو داره یا نه 🔐.

انواع هدر Authentication 🛡️

Basic Authentication 🔑
این ساده‌ترین نوع Authentication هستش. توی این روش، نام کاربری و پسورد به‌صورت base64 رمزگذاری میشن و بعد توی هدر قرار می‌گیرن. نمونه‌ای از هدرش این شکلیه:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

ولی چون اطلاعات رو به‌صورت ساده (حتی با وجود base64) می‌فرسته، خیلی امن نیست و معمولاً توی HTTPS ازش استفاده می‌کنن.


Bearer Token 🏷️
توی این روش، از یه توکن (Token) به‌جای نام کاربری و پسورد استفاده می‌کنن. این توکن معمولاً وقتی کاربر لاگین می‌کنه، از سرور می‌گیره و بعد توی درخواست‌ها به‌عنوان هدر ارسال میشه. هدرش این شکلیه:

Authorization: Bearer your-token-here 

این روش خیلی امن‌تر و محبوب‌تره، مخصوصاً توی API‌های مدرن و استفاده از JWT (JSON Web Tokens).

OAuth 2.0 🔑
این روش بیشتر برای احراز حویت با استفاده از سرویس‌های بزرگی مثل گوگل و فیسبوک استفاده میشه. توی این مدل، شما یه Access Token از طرف سرویس‌دهنده می‌گیرید و بعد اون رو توی هدر می‌فرستید. خیلی شبیه به Bearer Token:

Authorization: Bearer access-token 

چطوری از هدر Authentication استفاده کنیم؟ 💻
فرض کن یه API داری که برای دسترسی به یه سری اطلاعات حساس نیاز به احراز هویت داره. برای اینکه کاربر بتونه به این اطلاعات دسترسی داشته باشه، باید توی درخواستش هدر Authentication رو به‌درستی تنظیم کنه.

مثلاً برای ارسال یه درخواست به API با استفاده از Bearer Token:

curl -H "Authorization: Bearer your-token-here" https://api.example.com/data 

چرا هدر Authentication مهمه؟ 🛠️

1⃣ امنیت اطلاعات:
این هدر به سرور کمک می‌کنه مطمئن بشه که درخواست از یه کاربر معتبر ارسال شده.

2⃣ مدیریت دسترسی:
با استفاده از این هدر، می‌تونی سطح دسترسی‌های مختلف رو برای کاربرها تنظیم کنی. مثلاً بعضی کاربران فقط به بخش‌هایی از اپلیکیشن دسترسی داشته باشن.

3⃣ یکپارچگی با API:
خیلی از APIها مثل REST و GraphQL نیاز دارن که کاربر با ارسال هدر Authentication خودش رو احراز هویت کنه.

جمع‌بندی 🎯
فهمیدیم هدر Authentication یکی از پرکاربردترین ابزارها برای احراز هویت توی وب و APIهاست. روش‌های مختلفی برای استفاده ازش وجود داره، مثل Basic، Bearer Token و OAuth که بسته به نیازت می‌تونی از هرکدومشون استفاده کنی.

امید وارم مفید بوده باشه :)

#authentication #headers #security

@ninja_learn_ir

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

مثلاً توی موضوع lifetime متوجه شدم که خیلی از بچه‌ها فکر می‌کنند, وقتی
&’static str
میزنند، به اون string slice دارن lifetime جدیدی می‌دهند.

درصورتی که این برداشت اشتباه هست

موضوع lifetime annotation هم مثل موضوع generic هست، شما وقتی می‌زنی T: Display داری میگی که من دیتایی رو میدم که حتماً Display trait براش پیاده‌سازی شده.

توی مثال:
&’static str
شما میگی این دیتا می‌تونه lifetime به اندازه طول برنامه داشته باشه، اگر دیتایی بدید که این مقدار lifetime رو نداره کامپایل نمی‌شه و بهت ارور میده

موضوع بعدی قوانین lifetime مشخص کردن توی توابع هست (تحت چه شرایطی حتماً lifetime نیازه) که خب بنظرم باشه برای یک پست دیگری.

داشتم کد مینوشتم
یک گافه خیلی بد دادم اصلا حواسم نبود.
باگه این کد کجاست؟

@PyBackendHub

از طراحی گلدان و کفپوش پیاده روهای شهرداری تا طراحی لوگوی تیم فوتبال پرسپولیس

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

* آغاز فعالیت حرفه‌ای: استاد مستوفی از سال ۱۳۶۵ فعالیت حرفه‌ای خود را آغاز نمود و در همان ابتدای کار با کسب رتبه‌های برتر در مسابقات مختلف طراحی، توانایی‌های خود را به اثبات رساند.
* دوران شکوفایی: در دهه‌های ۷۰ و ۸۰، ایشان با طراحی لوگو و نشانه‌های بصری برای سازمان‌ها و شرکت‌های معتبر همچون فدراسیون بولینگ ایران، سازمان تبلیغات اسلامی، شهرداری تهران، سازمان صنایع ملی ایران و... به شهرتی فراگیر دست یافتند.
* همکاری با نهادهای علمی و فرهنگی: استاد مستوفی همواره به همکاری با نهادهای علمی و فرهنگی علاقه‌مند بوده و در طراحی نشانه‌ها و جلد کتاب‌های دانشگاهی، مراکز پژوهشی و انتشارات معتبر مشارکت داشته است.
* تدریس و پرورش نسل جدید طراحان: ایشان علاوه بر فعالیت حرفه‌ای، سال‌ها به تدریس طراحی در مراکز آموزشی مختلف پرداخته و در پرورش نسل جدید طراحان گرافیک نقش مؤثری داشته‌اند.
* طراح رسمی تیم‌های ورزشی: طراحی لوگوی تیم فوتبال پرسپولیس یکی از افتخارات بزرگ استاد مستوفی است که نشان از جایگاه ویژه‌ ایشان در حوزه طراحی ورزشی دارد.

کارنامه حرفه‌ای استاد مهران مستوفی، گنجینه‌ای ارزشمند از آثار طراحی گرافیک است که نشان از توانایی‌ها و مهارت‌های بالای ایشان در این حوزه دارد. آثار ایشان الهام‌بخش نسل‌های جدید طراحان بوده و به غنی‌سازی فرهنگ بصری کشور کمک شایانی کرده است.

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

@shirclub

🔵 عنوان مقاله
Garble: A Toolchain to Obfuscate Go Builds

🟢 خلاصه مقاله:
مقاله مورد نظر درباره روشی به نام Garble برای مخفی‌سازی اطلاعات در برنامه‌های نوشته شده با زبان برنامه‌نویسی Go بحث می‌کند. این ابزار، که مناسب برای نسخه‌های 1.22 و بالاتر Go است، به کاربران امکان می‌دهد تا اطلاعات کمتری را در مورد کد منبع اصلی در باینری‌های خود نگه دارند. با این حال، مقاله تأکید می‌کند که استفاده از روش‌های محافظتی مثل Garble به منزله تضمین امنیت کامل نیست، بلکه صرفاً یک راهکار برای کاهش میزان اطلاعات قابل استخراج از برنامه توسط افراد خارجی محسوب می‌شود. این تکنیک همچنین می‌تواند به عنوان یک بخشی از استراتژی امنیتی متعادل استفاده شود، اما نباید به عنوان تنها اقدام امنیتی در نظر گرفته شود.

🟣لینک مقاله:
https://golangweekly.com/link/159570/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

یک راهنمایی بزرگ:‌لاجیک کد مشکل نداره.
خروجی کنسول اینه:

Ma: Hirad
Hir: Hirad

در صورتی که باید Ma: Mani و Hir: Hirad باشه. چرا؟

@PyBackendHub

برای اینکه بفهمین چطور کار می‌کنه، اول یه مثال ساده‌تر رو در نظر بگیرین:

adders = []
for x in [1, 2, 3]:
    adders.append(lambda number: number + x)

for adder in adders:
    print(adder(3))

قاعدتاً باید خروجی‌ها ۴، ۵ و ۶ باشن، درسته؟ چون یه لیست از تابع‌های lambda داره که هر کدوم یه عدد می‌گیرن و x رو بهش اضافه می‌کنن.
ولی در واقع خروجی‌ها ۶، ۶ و ۶ هستن! چرا این اتفاق می‌افته؟
چون این lambdaها تو این مثال closure هستن. تو پایتون، توابع closure زمانی اجرا می‌شن که صدا زده بشن، نه وقتی که تعریف می‌شن! و به متغیرهایی که تو scopeشون هست رفرنس می‌زنن.

def foo():
    adders = []
    for x in [1, 2, 3]:
        adders.append(lambda number: number + x)
    return adders


def main():
    adders = foo()
    x = 5
    for adder in adders:
        print(adder(3))

تو این مثال، x یه بار تو foo تعریف شده و یه بار تو main. وقتی تو main اون closureها رو صدا می‌زنه که تو foo تعریف شده بودن، xی که استفاده می‌کنن همونیه که تو foo بوده، نه اون x تو main.یعنی الان تو این مثال x داخل lambda عدد ۳ میشه نه ۵.
چرا؟ چون داخلش توابع ‍closure یک cell هست که arguement رو ذخیره کرده. و تو همون اسکوپی که تعریف شده اون مدام آپدیت میشه اگه تغییر کنه. بنابراین اینجا چون scope تابع main دیگه با closureمون یکی نیست پس دیگه تغییر نمیکنه.


یک مقاله برای درک بهتر این موضوع تو medium
یک بلاگ راجب اشتباهات رایج تو پایتون این شکلی

@PyBackendHub

‏وقتی scala و Ruby یاد بگیرم باسن همه دولوپرای دورو برم میذارم!

<Rust/>

@DevTwitter

t.iss.one/tamozi_karaj

طموزی کرج:

#معرفی #موقت

ما طموزی هستیم، طرفداران محیط زیست
برای ایران 🇮🇷 برای زمین 🌏
محیط‌زیست سالم، حقّ اوّلیهٔ همهٔ موجودات

tamozi.ir
instagram.com/tamozi.ir
@tamozi
t.iss.one/+eujf7n6TFldkMjVk

#معرفی #موقت

لینک جدید دورهمی به علت محدودیت های پیش آمده


https://engage.shatel.com/b/soh-kwv-w45-csq

خسروپناه، دبیر شورای عالی انقلاب فرهنگی:
باید یه هوش‌مصنوعی مخصوص بسازیم و باهاش مملکتو اداره کنیم


اگر این خبر تأیید شد، از طرف خمینی بهش بگید:

خیلی خررررری

اگه به عنوان یه برنامه نویس چالش پروژه گرفتن دارید پست جدیدمون رو از دست ندید 😉

https://www.instagram.com/p/DAL0HKZos8Q/?utm_source=ig_web_copy_link&igsh=MzRlODBiNWFlZA==

نوشتن manifestهای کوبرنتیز میتونه چالش برانگیز باشه مخصوصا اگه تعداد microserviceها زیاد باشه

این مقاله یه سری best practice رو میگه که بهتر و منسجم تر بتونید manifestهارو بنویسید.


Best Practices for Writing Kubernetes YAML Manifests
https://mogenius.com/blog-posts/best-practices-for-writing-kubernetes-yaml-manifests


@gocasts

#devops
#kubernetes

اگه کلاینت#2 تصمیم بگیره داده قبلی رو به‌روزرسانی کنه، می‌تونه دوباره درخواست رو با هدر If-Match بفرسته. ولی اگه مقدار ETag توی هدر با مقدار فعلی منبع مطابقت نداشته باشه، API باید با کد 412 ("Precondition Failed") پاسخ بده. اما اگه شرط هدر مطابقت داشته باشه، API باید وضعیت منبع رو به‌روزرسانی کنه و با کد 200 ("OK") یا 204 ("No Content") پاسخ بده.
اگه API یه نمای جدید از وضعیت منبع رو برگردونه، باید هدرهای Last-Modified و ETag رو با مقادیر به‌روزرسانی شده توی پاسخ بذاره.


⭕️ استفاده از Location برای مشخص کردن URI منبع جدید
مقدار هدر Location یه URI هست که منبع جدیدی رو که ممکنه برای کلاینت مهم باشه، شناسایی می‌کنه. وقتی که API یه منبع جدید رو توی یه مجموعه یا فروشگاه ایجاد می‌کنه، باید هدر Location رو توی پاسخ قرار بده تا URI منبع جدید رو مشخص کنه.
توی پاسخ 202 ("Accepted")، این هدر می‌تونه کلاینت رو به وضعیت عملیاتی یه منبع کنترل غیرهمزمان (asynchronous controller) هدایت کنه.

⭕️ از هدرهای Cache-Control، Expires و Date برای کش کردن استفاده بشه
کش کردن یکی از قابلیت‌های مفید HTTP هست که می‌تونه به کاهش تأخیرهای تجربه‌شده توسط کلاینت، افزایش اطمینان‌پذیری، و کاهش بار روی سرورهای API کمک کنه. کش‌ها می‌تونن هر جایی باشن؛ توی شبکه‌ی سرور API، شبکه‌های تحویل محتوا (CDN)، یا حتی شبکه‌ی کلاینت.
وقتی که یه نمایشی از داده رو ارسال می‌کنی، باید هدر Cache-Control رو با مقدار max-age (به ثانیه) قرار بدی تا طول عمر تازگی داده رو مشخص کنی. به عنوان مثال:

Cache-Control: max-age=60, must-revalidate

برای پشتیبانی از کش‌های قدیمی HTTP 1.0، API باید هدر Expires رو با یه تاریخ و زمان انقضا قرار بده. این مقدار برابر با زمانی هست که API داده رو تولید کرده به اضافه‌ی طول عمر تازگی داده. همچنین API باید هدر Date رو با تاریخ و زمانی که پاسخ رو برگردونده، بذاره. این هدر کمک می‌کنه کلاینت‌ها طول عمر تازگی داده رو به‌عنوان اختلاف بین مقادیر Expires و Date محاسبه کنن. به عنوان مثال:

Date: Tue, 15 Nov 1994 08:12:31 GMT
Expires: Thu, 01 Dec 1994 16:00:00 GMT

⭕️ از هدرهای Cache-Control، Expires و Pragma میشه برای جلوگیری از کش استفاده کرد
اگه پاسخ API نباید کش بشه، باید هدر Cache-Control با مقادیر no-cache و no-store قرار بگیره. برای سازگاری با کش‌های قدیمی HTTP 1.0، هدرهای Pragma: no-cache و Expires: 0 هم باید اضافه بشن.


⭕️ کش کردن باید تشویق بشه
استفاده از no-cache باعث میشه هیچ کشی نتونه پاسخ‌های کش شده رو ارائه بده. APIهای REST نباید از این دستور استفاده کنن، مگر اینکه واقعاً ضروری باشه. به‌جای استفاده از `no-cache`، بهتره مقدار کمی برای max-age تنظیم بشه تا کلاینت‌ها بتونن حداقل برای یه مدت کوتاه از نسخه‌های کش شده استفاده کنن، بدون اینکه تازگی داده‌ها به طور قابل توجهی تحت تاثیر قرار بگیره.


⭕️ هدرهای کش‌کردن باید با پاسخ‌های 200 (“OK”) استفاده بشن
تو پاسخ‌های موفقیت‌آمیز GET و HEAD باید هدرهای کش‌کردن انقضا قرار داده بشن. هرچند روش POST هم قابل کش شدنه، اکثر کش‌ها اون رو به عنوان غیرقابل کش در نظر می‌گیرن. نیازی نیست این هدرها رو برای متدهای دیگه تنظیم کنی.

⭕️ هدرهای کش‌کردن می‌تونن به‌صورت اختیاری با پاسخ‌های 3xx و 4xx استفاده بشن
علاوه بر پاسخ‌های موفقیت‌آمیز 200 (“OK”)، می‌تونی تو پاسخ‌های 3xx و 4xx هم هدرهای کش‌کردن اضافه کنی. این کار که بهش کش‌کردن منفی میگن، کمک می‌کنه تا بار ریدایرکت‌ها و خطاها روی API کاهش پیدا کنه.

⭕️ از هدرهای HTTP سفارشی نباید برای تغییر رفتار متدهای HTTP استفاده بشه
هدرهای سفارشی رو میشه فقط برای اطلاع‌رسانی استفاده کرد. کلاینت‌ها و سرورها باید به شکلی پیاده‌سازی بشن که وقتی هدرهای سفارشی مورد انتظار رو پیدا نمی‌کنن، دچار خطا نشن.
اگه اطلاعاتی که توی هدر سفارشی قرار میدی برای تفسیر درست درخواست یا پاسخ ضروریه، بهتره اون اطلاعات رو توی بدنه درخواست یا پاسخ، یا توی URI استفاده کنی. از هدرهای سفارشی برای این کاربردها اجتناب کن.

@ninja_learn_ir

📕 کتاب REST API Design Rulebook

📌 فصل چهارم: Metadata Design

📍پارت: اول

#کتاب

‏💎 HTTP Headers 💎
توی درخواست و پاسخ‌های HTTP، یه سری اطلاعات متا (Metadata) از طریق هدرهای مختلف منتقل می‌شن. HTTP یه سری هدر استاندارد داره که بعضیاشون درباره منابع درخواست شده اطلاعات میدن. یه سری دیگه نشون میدن که چه نوع دیتایی توی پیام وجود داره. یه تعداد دیگه هم برای کنترل کش (Cache) استفاده میشن.

توی این متن کوتاه چندتا قانون مهم برای استفاده از هدرهای استاندارد HTTP توی طراحی REST API ها پیشنهاد شده.

⭕️ استفاده از Content-Type اجباریه
هدر Content-Type نوع داده‌ای که توی body درخواست یا پاسخ هست رو مشخص می‌کنه. مقدار این هدر یه رشته متنی با فرمت خاصه که بهش "Media Type" گفته میشه. سرور و کلاینت با استفاده از مقدار این هدر متوجه میشن چطوری باید بایت‌های موجود توی بدنه پیام رو پردازش کنن.

⭕️ استفاده از Content-Length توصیه میشه
هدر Content-Length اندازه بدنه پیام (entity-body) رو بر حسب بایت مشخص می‌کنه. این هدر توی پاسخ‌ها مهمه چون دو تا کار رو راحت می‌کنه:
اول اینکه کلاینت متوجه میشه که آیا تعداد بایت‌های درست رو خونده یا نه. دوم اینکه می‌تونه با یه درخواست HEAD بفهمه که اندازه بدنه پیام چقدره بدون اینکه نیاز باشه کل پیام رو دانلود کنه.

⭕️ استفاده از Last-Modified توی پاسخ‌ها توصیه میشه
هدر Last-Modified فقط توی پیام‌های پاسخ استفاده میشه. مقدار این هدر یه timestamp (زمان دقیق) هست که نشون میده آخرین باری که چیزی توی منابع تغییر کرده کی بوده. کلاینت و کش‌های میانی (Cache Intermediaries) می‌تونن از این هدر استفاده کنن تا بفهمن نسخه محلی‌شون از منبع به‌روز هست یا نه. این هدر باید همیشه توی پاسخ به درخواست‌های GET باشه.

⭕️ استفاده از ETag توی ریسپانس ها توصیه میشه
مقدار ETag یه رشته متنی غیرشفافه (opaque) که یه "نسخه" خاص از منبع (Resource) توی body ریسپانس رو شناسایی می‌کنه. body پیام HTTP شامل هدرها و body اصلی پیام میشه. مقدار ETag می‌تونه هر رشته‌ای باشه، به شرطی که وقتی نمایشی از منبع تغییر می‌کنه، مقدارش هم تغییر کنه. این هدر باید همیشه توی پاسخ به درخواست‌های GET ارسال بشه.

کلاینت‌ها می‌تونن مقدار هدر ETag رو ذخیره کنن تا توی درخواست‌های GET بعدی، ازش استفاده کنن؛ به عنوان مقدار هدر شرطی If-None-Match. اگه API تشخیص بده که ETag تغییر نکرده، می‌تونه از ارسال دوباره‌ی بدنه پیام صرف‌نظر کنه و در نتیجه توی زمان و پهنای باند صرفه‌جویی بشه.


@ninja_learn_ir

‏⭕️ store ها باید از درخواست‌های شرطی PUT پشتیبانی کنن
وقتی برای ذخیره یه منبع از متد PUT استفاده می‌کنه (چه برای ایجاد و چه به‌روزرسانی)، ممکنه برای API مشخص نباشه که درخواست کلاینت برای درج داده جدیده یا به‌روزرسانی. اینجاست که HTTP از طریق هدرها ابزار لازم رو در اختیار API میذاره تا این ابهام رو برطرف کنه. برای این کار، API باید به هدرهای شرطی کلاینت مثل If-Unmodified-Since یا If-Match متکی باشه تا منظور دقیق کلاینت رو بفهمه.

هدر If-Unmodified-Since از API می‌خواد که فقط در صورتی عملیات رو انجام بده که از زمانی که توی این هدر مشخص شده، وضعیت منبع تغییری نکرده باشه.

هدر If-Match یه مقدار ETag رو از کلاینت می‌گیره، که از پاسخ قبلی API ذخیره شده. اگه این مقدار ETag با وضعیت فعلی منبع مطابقت داشته باشه، API درخواست PUT رو انجام میده؛ وگرنه درخواست رو رد می‌کنه.

✅ مثال برای درخواست‌های شرطی PUT

فرض کنیم دو کلاینت (کلاینت#1 و کلاینت#2) از یه منبع ذخیره‌ی API با آدرس /objects برای اشتراک‌گذاری اطلاعات استفاده می‌کنن.

کلاینت#1 یه درخواست PUT می‌فرسته تا یه داده جدید توی مسیر /objects/2113 ذخیره کنه. این مسیر قبلاً توی API وجود نداشته، پس API این درخواست رو به‌عنوان "ایجاد" (Insert) تفسیر می‌کنه، منبع جدید رو می‌سازه و با کد 201 ("Created") پاسخ میده.

چند وقت بعد، کلاینت#2 درخواست PUT برای همون مسیر (/objects/2113) می‌فرسته. حالا API این مسیر رو به یه منبع موجود متصل می‌کنه. اما چون اطلاعات کافی نداره که بفهمه آیا کلاینت#2 می‌خواد داده‌ی قبلی رو به‌روزرسانی کنه یا نه، درخواست رو با کد 409 ("Conflict") رد می‌کنه و باید توی بدنه پاسخ هم یه توضیح از خطا بده.

@ninja_learn_ir