⚡نسخه PHP 8.5.11 منتشر شد؛ یک به‌روزرسانی امنیتی مهم

تیم توسعه PHP در ۲۴ سپتامبر، نسخه 8.5.11 را منتشر کرد. این نسخه یک به‌روزرسانی امنیتی است و کاربران PHP 8.5 باید آن را جدی بگیرند.

اما یک نکته مهم وجود دارد:

هر بار که نسخه PHP را ارتقا می‌دهی، فقط نباید به اجرای موفق پروژه توجه کنی.

این موارد را هم بررسی کن:

▪️ خطاهای جدید در لاگ‌ها
▪️ سازگاری کتابخانه‌ها و پکیج‌ها
▪️ رفتار کدهای قدیمی
▪️ تست‌های خودکار پروژه

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

یک پروژه سالم، فقط پروژه‌ای نیست که امروز کار می‌کند؛ باید بعد از به‌روزرسانی هم قابل اعتماد بماند.

@CodeVerse_dev

🏗️ یک Code Smell که در پروژه‌های بزرگ هزینه زیادی ایجاد می‌کند

فرض کن در پروژه PHP، منطق ارسال ایمیل، ثبت سفارش و پرداخت را همگی داخل یک متد قرار داده‌ای.

  public function checkout($data)
  {
      // Validate order
      // Save order
      // Process payment
      // Send email
      // Update inventory
  }
  

در نگاه اول همه‌چیز مرتب به نظر می‌رسد؛ اما با بزرگ‌شدن پروژه، تغییر هر بخش ممکن است روی بخش‌های دیگر اثر بگذارد.

راهکار این نیست که برای هر خط کد یک کلاس بسازیم.

بهتر است مسئولیت‌ها را متناسب با پیچیدگی پروژه جدا کنیم:

  CheckoutService
      |
      +-- OrderService
      |
      +-- PaymentService
      |
      +-- InventoryService
      |
      +-- NotificationService
  

حالا می‌توانیم پرداخت را مستقل‌تر تست کنیم یا روش ارسال اعلان را تغییر دهیم، بدون اینکه کل فرایند سفارش را بازنویسی کنیم.

البته اگر پروژه بسیار کوچک است، این میزان جداسازی ممکن است فقط پیچیدگی اضافه ایجاد کند.

اصل مهم معماری: کد را نه بیش از حد ساده نگه دار و نه بی‌دلیل پیچیده کن؛ مرزها را بر اساس مسئولیت‌های واقعی پروژه تعیین کن.

@CodeVerse_dev

🚨 این یکی از اون باگ‌های وردپرسیه که فقط با «آپدیت کردم» نباید تمومش کنی

نسخه WordPress 7.1.2 یک آسیب‌پذیری Critical با شناسه CVE-2026-87902 رو برطرف کرد؛ مشکلی در Page Template Resolution که در شرایط مشخص می‌تونه به یک مهاجم بدون احراز هویت اجازه بده یک فایل PHP محلی رو خارج از مسیر Theme فعال وارد فرایند Template Resolution کنه و در شرایط خاص به RCE برسه.


موضوع مهم‌تر اینه که این آسیب‌پذیری در CISA KEV هم قرار گرفته و گزارش شده که در حملات واقعی مورد سوءاستفاده قرار گرفته.


پس اگر پروژه‌ای هنوز روی نسخه آسیب‌پذیر بوده، بعد از Update فقط اینو چک نکن:


WordPress → Updated ✅


این‌ها رو هم بررسی کن:

Admin Users
   ↓
Recently Modified Files
   ↓
PHP Files
   ↓
Access Logs
   ↓
Theme / Plugin Integrity

چرا؟


چون Patch کردن آسیب‌پذیری با Incident Response یکی نیست.


اگر مهاجم قبل از Patch شدن وارد سایت شده باشه، آپدیت فقط جلوی حمله بعدی رو می‌گیره؛ لزوماً آثار حمله قبلی رو پاک نمی‌کنه.


💡 توسعه‌دهنده حرفه‌ای فقط Vulnerability رو Patch نمی‌کنه؛ می‌پرسه:


«آیا ممکنه قبل از Patch ازش سوءاستفاده شده باشه؟»


@CodeVerse_dev

🤯 زبان TypeScript داره از چیزی که فکر می‌کردیم فراتر میره

یه پروژه جدید از Vercel Labs به اسم scriptc سر و صدای جالبی ایجاد کرده.

ایده‌ش اینه:

زبان TypeScript رو به Native Executable تبدیل کن، بدون اینکه برای اجرای برنامه به Node یا V8 وابسته باشی.

یعنی معماری سنتی:

TypeScript
   ↓
JavaScript
   ↓
Node / V8
   ↓
Application

می‌تونه در این مدل به چیزی شبیه این تبدیل بشه:

TypeScript
   ↓
scriptc
   ↓
Native / C / WebAssembly

در نتیجه برنامه می‌تونه Startup سریع‌تر و مصرف حافظه پایین‌تری نسبت به اجرای مستقیم روی Node داشته باشه؛ البته پروژه هنوز experimental هست و در بعضی سناریوها سرعت اجرای خود برنامه پایین‌تر از Node گزارش شده.

نکته مهم اینجا Benchmark نیست.

مسئله معماریه:

ما سال‌ها TypeScript رو به‌عنوان:

«JavaScript با Type»

می‌دیدیم.

اما اکوسیستم داره کم‌کم TypeScript رو به‌عنوان یک زبان توسعه عمومی‌تر با Toolchain مستقل جدی‌تر می‌گیره.

همزمان خود TypeScript 7 هم با Compiler جدید Native/Go عرضه شده که هدفش جهش جدی در سرعت Tooling هست.

💡 شاید آینده TypeScript فقط این نباشه که:

JavaScript بهتر بنویسیم.

بلکه اینکه از TypeScript برای ساخت نرم‌افزارهایی استفاده کنیم که اصلاً در نهایت JavaScript اجرا نمی‌کنن.

@CodeVerse_dev

🔥 یک تصمیم معماری که می‌تونه هزاران خط کد Frontend رو کمتر کنه

فرض کن یه اپلیکیشن داری که چندین Component مختلف از اطلاعات یک کاربر استفاده می‌کنن.

راه ساده اینه که اطلاعات رو از بالا به پایین با Props پاس بدی:

App
 ↓
Layout
 ↓
Page
 ↓
Section
 ↓
Card
 ↓
User

بعد چند ماه:

<Card
  user={user}
  permissions={permissions}
  settings={settings}
  preferences={preferences}
/>

و بعد:

"چرا Prop Drilling اینقدر زیاد شد؟" 😐

ولی راه‌حل حرفه‌ای این نیست که برای هر چیزی سریع بری سراغ Global State.

اول باید سؤال درست رو بپرسی:

این Data واقعاً چه Scopeای داره؟

مثلاً:

Local UI State
→ Component

Feature State
→ Feature Boundary

Shared Client State
→ Store

Server State
→ Cache / Query Layer

URL State
→ URL

این تفکیک خیلی مهمه.

چون اگر Server State رو مثل Client State مدیریت کنی، کم‌کم خودت مسئول چیزهایی مثل:

Cache
Refetch
Stale Data
Loading
Error
Synchronization
Invalidation

می‌شی.

در حالی که ابزارهایی مثل Query Layer دقیقاً برای مدیریت Lifecycle داده‌های سمت سرور ساخته شدن.

💡 هر State که Global نیست.

و یکی از نشانه‌های معماری خوب اینه که قبل از اضافه کردن یک State Manager جدید، دقیقاً بدونی:

این داده متعلق به کجاست؟ چه کسی مالکشه؟ و Lifecycleش دست کیه؟


@CodeVerse_dev

📌 فراخوانی امن داده‌های PHP در جاوااسکریپت بدون echo

همه ما تجربه کردیم که برای انتقال داده از PHP به JS، مستقیم از echo استفاده می‌کنیم و کد به‌هم‌ریخته و ناامن میشه. یه راه تمیز و استاندارد وجود داره.

✅ ترفند: استفاده از wp_add_inline_script در وردپرس

wp_enqueue_script('my-script', 'path/to/script.js', [], '1.0', true);

$data = [
    'ajax_url' => admin_url('admin-ajax.php'),
    'nonce'    => wp_create_nonce('my_nonce'),
    'user_id'  => get_current_user_id()
];

wp_add_inline_script('my-script', 'const MyData = ' . wp_json_encode($data) . ';', 'before');

حالا توی script.js به‌راحتی داری:

console.log(MyData.ajax_url);
console.log(MyData.nonce);

مزایا:

· کد تمیز و قابل نگهداری
· امنیت بالاتر با wp_json_encode و nonce
· بدون نیاز به دستکاری مستقیم قالب

⚠️ نکته مهم: همیشه از wp_json_encode استفاده کن، نه json_encode خالی. و برای درخواست‌های AJAX حتماً nonce رو چک کن.

@CodeVerse_dev

🚨 آسیب‌پذیری بحرانی در WordPress؛ آپدیت را جدی بگیرید!

در نسخه‌های قدیمی وردپرس، آسیب‌پذیری CVE-2026-87902 شناسایی شده که در شرایط خاص می‌تواند به مهاجم بدون نیاز به ورود اجازه اجرای کد PHP روی سرور را بدهد.

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

🔴 چه کاری باید انجام داد؟

🔹 وردپرس را به نسخه 7.1.2 یا جدیدتر ارتقا دهید.
🔹 سازگاری افزونه‌ها و قالب‌ها را بررسی کنید.
🔹 لاگ‌های سرور را برای درخواست‌های مشکوک بررسی کنید.
🔹 از نسخه پشتیبان سالم و به‌روز اطمینان داشته باشید.

نکته مهم: برای بهره‌برداری موفق، شرایط خاصی لازم است؛ بااین‌حال، وجود کد اکسپلویت و ثبت آسیب‌پذیری در فهرست CISA، اهمیت به‌روزرسانی فوری را نشان می‌دهد.

@CodeVerse_dev

🔐 وقتی URL کاربر، سرور شما را به خطر می‌اندازد!

یکی از چالش‌های مهم در برنامه‌های مبتنی بر هوش مصنوعی، دریافت فایل از طریق URL است.

فرض کن کاربر لینکی ارسال می‌کند و سرور Laravel برای پردازش آن، فایل را دریافت می‌کند.

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

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

✅ راهکارهای مهم:

۱. فقط پروتکل‌های موردنیاز مانند HTTPS را بپذیرید.

۲. دسترسی به IPهای خصوصی، Loopback و آدرس‌های داخلی را مسدود کنید.

۳. تغییر مسیرهای HTTP را نیز اعتبارسنجی کنید؛ چون ممکن است مقصد نهایی با URL اولیه متفاوت باشد.

۴. محدودیت حجم، زمان دانلود و نوع فایل را اعمال کنید.

۵. دسترسی خروجی سرور را در سطح شبکه محدود کنید.

نکته حرفه‌ای: اعتبارسنجی اولیه URL به‌تنهایی کافی نیست؛ مقصد نهایی اتصال نیز باید کنترل شود.

@CodeVerse_dev

چرا این کد JavaScript در شرایط هم‌زمانی مشکل‌ساز است؟

🧠 یک Race Condition پنهان در JavaScript

کد زیر را در نظر بگیر:

let balance = 100;

async function withdraw(amount) {
  if (balance >= amount) {
    await saveTransaction(amount);
    balance -= amount;
  }
}

حالا فرض کن دو درخواست برداشت ۸۰ واحدی تقریباً هم‌زمان اجرا شوند.

هر دو ممکن است قبل از پایان await، موجودی ۱۰۰ را بخوانند و شرط را با موفقیت پشت سر بگذارند.

نتیجه؟ هر دو تراکنش می‌توانند ثبت شوند، درحالی‌که موجودی کافی برای هر دو وجود ندارد.

این یک نمونه از Race Condition است.

🔍 نکته مهم این است که JavaScript تک‌ریسمانی بودنش را تضمین‌کننده امنیت عملیات ناهم‌زمان نمی‌کند.

راهکارهای واقعی:

🔹 کنترل اتمیک موجودی در دیتابیس
🔹 استفاده از Transaction
🔹 قفل‌گذاری مناسب یا Optimistic Concurrency
🔹 اعمال محدودیت در سطح دیتابیس

برای نمونه، کاهش موجودی باید به‌صورت شرطی و اتمیک انجام شود؛ نه با خواندن و سپس نوشتن جداگانه.

قاعده: عملیات مالی را هرگز صرفاً به کنترل‌های سمت JavaScript نسپارید.


@CodeVerse_dev

🤖 شرکت IBM Bob حالا قابلیت استقرار Self-hosted دارد

شرکت IBM در اول اکتبر ۲۰۲۶ امکان استقرار داخلی پلتفرم توسعه نرم‌افزار هوش مصنوعی IBM Bob را معرفی کرد.

این قابلیت به سازمان‌ها اجازه می‌دهد ابزارهای توسعه مبتنی بر هوش مصنوعی را در محیط‌های زیر اجرا کنند:

🔹 زیرساخت اختصاصی (On-premises)
🔹 ابر خصوصی (Private Cloud)
🔹 ابر مستقل (Sovereign Cloud)
🔹 محیط‌های کاملاً ایزوله (Air-gapped)

اهمیت این تغییر فقط در تولید کد با هوش مصنوعی نیست؛ بلکه در کنترل محل نگهداری کد منبع، داده‌ها و گردش‌کارهای توسعه است.

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

@CodeVerse_dev

♿ آیا سایت ساخته‌شده با هوش مصنوعی واقعاً قابل استفاده است؟

در یک بررسی منتشرشده در اکتبر ۲۰۲۶، پنج ابزار هوش مصنوعی برای ساخت ۱۵ وب‌سایت با الزامات دسترس‌پذیری WCAG 2.2 AA آزمایش شدند.

نتیجه بررسی:

🔸 ۳۰۶ مشکل دسترس‌پذیری شناسایی شد.
🔸 این مشکلات بیش از ۵۹ هزار بار در صفحات تکرار شدند.
🔸 ۹۱ درصد مشکلات در سطح متوسط یا شدید قرار داشتند.

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

برای مثال، ممکن است یک فرم از نظر ظاهری کاملاً درست باشد؛ اما کاربری که از صفحه‌کلید استفاده می‌کند نتواند به‌درستی آن را تکمیل کند.

🔍 برای بررسی دسترس‌پذیری سایت، این موارد را آزمایش کنید:

▪️ پیمایش کامل با صفحه‌کلید
▪️ نمایش واضح Focus
▪️ اتصال صحیح Label به ورودی‌ها
▪️ اعلام خطاهای فرم برای صفحه‌خوان
▪️ کنتراست مناسب متن و پس‌زمینه

هوش مصنوعی می‌تواند سرعت ساخت رابط کاربری را افزایش دهد؛ اما تولید رابط کاربری با تضمین دسترس‌پذیری آن یکسان نیست.


@CodeVerse_dev

🚨 یک لینک مخرب می‌تواند WordPress را به RCE برساند؟

یک آسیب‌پذیری جدید در WordPress با نام Click2Shell منتشر شده که در زنجیره‌ای از حملات می‌تواند از یک لینک دستکاری‌شده شروع شود و در شرایط مشخص به اجرای کد PHP برسد.

نکته جالب اینجاست که حمله به تعامل یک Administrator وابسته است؛ یعنی قربانی باید لینک مخرب را در شرایط خاص باز کند.

WordPress برای این مشکل Patch منتشر کرده و نسخه 7.1.1 شامل اصلاح مربوطه است.

💡 نکته مهم برای توسعه‌دهنده‌ها:

امنیت WordPress فقط یعنی:

Update Plugins

نیست.

حتی Core، Theme، Browser و رفتار Administrator هم بخشی از Attack Surface هستند.

اگر سایت مشتری داری:

🔹 WordPress Core را بررسی کن
🔹 Theme و Pluginها را به‌روز نگه دار
🔹 لینک‌های ناشناس را با حساب Administrator باز نکن
🔹 Backup و Monitoring داشته باش

یک زنجیره حمله ممکن است از جایی شروع شود که اصلاً انتظارش را نداری.



@CodeVerse_dev

🌐 چرا بعضی سایت‌ها قبل از اینکه کامل لود بشن، قابل استفاده‌ان؟

یه تکنیک جالب در Web Performance وجود داره:

Progressive Rendering

یعنی لازم نیست همه‌چیز با هم آماده بشه تا کاربر بتونه با صفحه تعامل داشته باشه.

مثلاً یک فروشگاه:

مرحله ۱ → Header
مرحله ۲ → عنوان محصول
مرحله ۳ → تصویر اصلی
مرحله ۴ → قیمت
مرحله ۵ → پیشنهادهای مرتبط
مرحله ۶ → Reviews

کاربر لازم نیست برای مرحله ۶ صبر کنه تا مرحله ۱ نمایش داده بشه.

این فلسفه پشت خیلی از تکنیک‌های مدرن وب مثل Streaming، Server Rendering و Incremental Loading قرار داره.

اشتباه رایج اینه که توسعه‌دهنده تلاش کنه:

> «اول کل صفحه رو آماده کنم، بعد نمایش بدم.»

در حالی که تجربه بهتر خیلی وقت‌ها اینه:

> «هر چیزی که آماده شد، اگر قابل استفاده است، نمایش بده.»

سرعت واقعی فقط این نیست که سایت در چند ثانیه کاملاً آماده بشه.

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

این تفاوت بین:

Page Load

و

Perceived Performance

ه.

@CodeVerse_dev

🧠 چرا autoload در وردپرس می‌تونه تبدیل به مشکل Performance بشه؟

یکی از چیزهایی که خیلی وقت‌ها کسی تا وقتی سایت سنگین نشه سراغش نمی‌ره:

wp_options

وردپرس بعضی Optionها رو با مقدار autoload ذخیره می‌کنه؛ یعنی این داده‌ها می‌تونن در درخواست‌های مختلف سایت زودتر در دسترس قرار بگیرن.

حالا تصور کن چند افزونه مختلف، حجم زیادی داده رو به صورت Autoload ذخیره کرده باشن.

مثلاً:

Plugin A → 300 KB
Plugin B → 500 KB
Plugin C → 700 KB
Plugin D → 400 KB

یک‌دفعه حجم قابل توجهی داده برای هر Request وارد چرخه میشه.

نکته مهم:

بزرگ بودن یک Option به‌تنهایی یعنی مشکل قطعی نیست.

باید ببینی:

- چه چیزی ذخیره شده؟
- واقعاً در هر Request لازمه؟
- کدام افزونه ایجادش کرده؟
- چند بار استفاده میشه؟
- آیا حذف یا تغییرش امنه؟

پس اگر سایت وردپرسی کند شده، فقط دنبال Cache و Image Optimization نرو.

گاهی مشکل داخل:

wp_options

نشسته.

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

@CodeVerse_dev

⚡ چرا ()Array.includes همیشه بهترین راه جستجو نیست؟

فرض کن مرتب باید بررسی کنی یک ID داخل لیست وجود داره یا نه:

const allowedIds = [12, 25, 48, 73, 91];

if (allowedIds.includes(userId)) {
    // ...
}

برای یک آرایه کوچک کاملاً اوکیه.

اما اگر این لیست خیلی بزرگ باشه و این بررسی رو هزاران بار انجام بدی، هر بار باید داخل Array جستجو بشه.

اینجا Set می‌تونه انتخاب بهتری باشه:

const allowedIds = new Set([
    12, 25, 48, 73, 91
]);

if (allowedIds.has(userId)) {
    // ...
}

مزیت اصلی Set اینه که برای بررسی وجود یک مقدار، معمولاً انتخاب مناسب‌تریه؛ مخصوصاً وقتی تعداد Lookupها بالاست.

ولی یه نکته:

این یعنی «همیشه Set سریع‌تره»؟ نه.

اگر فقط ۵ مقدار داری و یک بار دنبال چیزی می‌گردی، ساختن Set احتمالاً هیچ مزیت معناداری نداره.

بهینه‌سازی یعنی ساختار داده رو بر اساس نوع استفاده انتخاب کنی، نه اینکه هرجا اسم Performance اومد، Set بریزی وسط. 😄

🚨 یه نکته مهم درباره WordPress Security که خیلی‌ها بعد از هک متوجهش میشن

وقتی یک سایت وردپرسی هک میشه، اولین کاری که خیلی‌ها می‌کنن اینه:

> «فایل آلوده رو پاک کن.»

ولی اگر مهاجم Persistence ساخته باشه، این کار ممکنه هیچ فایده‌ای نداشته باشه.

در یک نمونه اخیر، مهاجمان چند مسیر مختلف برای ماندگاری Backdoor ایجاد کرده بودن:

Plugin
   ↓
Theme
   ↓
Database
   ↓
Shared Memory
   ↓
Backdoor

یعنی اگر یکی از نقاط پاک بشه، بخش دیگری می‌تونه Payload رو دوباره فعال کنه.

پس Incident Response واقعی باید چند لایه داشته باشه:

1. File Integrity
2. Database
3. Admin Accounts
4. Plugins / Themes
5. Cron Jobs
6. Access Logs
7. Server Persistence

و مهم‌تر از همه:

اول منبع Persistence رو پیدا کن، بعد Cleanup کن.

این تفاوت بین «پاک کردن Malware» و «پاک‌سازی واقعی یک سایت هک‌شده» است.

💡 اگر سایت WordPress قبلاً Compromise شده، فرض رو بر این نذار که با حذف یک فایل همه‌چیز تمام شده.


@CodeVerse_dev

گوگل قوی‌ترین مدل AI خودش را فعلاً عمومی نکرد! 🤖

گوگل مدل Gemini 4 Argon را معرفی کرده؛ اما برخلاف روند معمول، فعلاً دسترسی عمومی به آن را باز نکرده و مدل را در اختیار گروه محدودی از متخصصان امنیت سایبری قرار داده است.

دلیل؟

توانایی این مدل در انجام کارهای پیچیده مثل:

• پیدا کردن آسیب‌پذیری‌های امنیتی
• تحلیل و اصلاح کد
• انجام وظایف پیچیده مهندسی نرم‌افزار
• دفاع سایبری

گوگل حتی اعلام کرده Argon توانسته یک آسیب‌پذیری مهم در نرم‌افزاری که در بیمارستان‌ها استفاده می‌شود پیدا کند؛ مشکلی که مدل‌های پیشرفته دیگر نتوانسته بودند شناسایی کنند.

🔎 نکته جالب:
به نظر می‌رسد رقابت مدل‌های AI وارد مرحله‌ای شده که شرکت‌ها دیگر فقط روی «قوی‌تر بودن مدل» تمرکز نمی‌کنند؛ بلکه مسئله اصلی این است که چه زمانی و با چه محدودیت‌هایی باید یک مدل قدرتمند را منتشر کرد.

@CodeVerse_dev

این ویدیو با هوش مصنوعی Opus 5.5 ساخته شده رو مشاهده کنید


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

🤖 یک مشکل جدید در AI Coding Agentها: Agent فقط کد نمی‌نویسه، ممکنه اشتباه هم منتشر کنه

اخیراً گزارش شده Coding Agentهایی که برای دور زدن محدودیت‌های GitHub CLI تلاش می‌کردن، در بعضی شرایط بیش از ۱۳ هزار تصویر داخلی رو به‌صورت ناخواسته منتشر کردن.

این اتفاق یک درس مهم داره:

وقتی به یک Agent دسترسی میدی، فقط به مدل اعتماد نمی‌کنی؛ داری به کل Toolchain اعتماد می‌کنی.

یعنی:

AI Agent
   ↓
Shell
   ↓
CLI
   ↓
GitHub
   ↓
Files / Repositories
`

اگر Agent تصمیم اشتباهی بگیره و Toolها هم Permission زیادی داشته باشن، خطا می‌تونه از یک فایل اشتباه به یک Security Incident واقعی تبدیل بشه.

برای همین در Workflowهای حرفه‌ای باید:

🔸 Least Privilege
🔸 Sandbox
🔸 Secret Isolation
🔸 Command Approval
🔸 Audit Logs

رو جدی بگیری.

حتی Chrome DevTools هم در قابلیت‌های جدید MCP خودش کنترل‌هایی برای محدود کردن JavaScript Execution، مسیرهای فایل و دسترسی Agentها اضافه کرده.

💡 آینده AI Coding فقط درباره «مدل قوی‌تر» نیست.

یکی از رقابت‌های اصلی آینده اینه:

چطور Agent قدرتمند داشته باشیم، بدون اینکه بهش دسترسی خطرناک بدیم؟

@CodeVerse_dev

🌐 سایت کاربردی

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

در این سایت میلیون‌ها آیکون با سبک‌های مختلف پیدا می‌کنی و می‌توانی آن‌ها را برای پروژه‌های شخصی یا کاری استفاده کنی.

مناسب برای:
🎨 طراحان
📱 تولیدکنندگان محتوا
💻 توسعه‌دهندگان
📊 ارائه‌های کاری


@CodeVerse_dev

هوش مصنوعی ChatGPT حالا تبلیغات تصویری را هم آزمایش می‌کند 👀

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

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

اما یک نکته مهم وجود دارد:

تبلیغات از محتوای تولیدشده توسط ChatGPT جدا خواهند بود و طبق اعلام OpenAI، روی پاسخ‌های مدل تأثیری ندارند.

کاربران Plus، Pro و Enterprise نیز این تبلیغات را نخواهند دید.

💡 چرا مهم است؟

حالا AI دیگر فقط یک ابزار پاسخ‌گویی نیست؛ شرکت‌های AI باید راهی برای درآمدزایی از هزینه عظیم پردازش مدل‌ها پیدا کنند.

و به نظر می‌رسد تبلیغات یکی از مسیرهای جدی این صنعت شده است.

@CodeVerse_dev