لما يضغط المستخدم «الدخول بحساب Google» وتطلع له صفحة من Google مكتوب فيها Error 400: redirect_uri_mismatch، معناه إن Google رفض يكمّل، لأن الرابط اللي طلب منتجك يرجع له المستخدم مو مسجّل عنده. وفيه مشكلة قريبة منها: الدخول ينجح، لكن المستخدم يرجع على localhost بدل موقعك. الاثنين من نفس العائلة: إعدادات روابط الرجوع.
إيش يصير وراء الزر
تسجيل الدخول بـ Google يمشي كذا: منتجك يرسل المستخدم لـ Google ومعه رابط اسمه redirect URI، يعني «بعد ما يدخل، رجّعه هنا». Google ما يرجّع أحد على رابط إلا إذا كان مسجّل مسبقًا في إعدادات تطبيقك عنده في Google Cloud Console. وهذا مقصود: لو يقبل أي رابط، أي أحد يقدر يرجّع جلسة دخول مستخدمك لموقعه هو.
والتطابق صارم، حرف بحرف: http غير https، و www.example.com غير example.com، وحتى الشرطة المائلة في آخر الرابط تفرق.
ليش يصير كثير في المنتجات المبنية بالذكاء الاصطناعي
- في Lovable و Bolt غالبًا الدخول يمر عن طريق Supabase. هنا الرابط اللي لازم يتسجّل في Google هو رابط Supabase نفسه، اللي شكله
https://xxxx.supabase.co/auth/v1/callback، مو رابط موقعك. كثير يسجّلون رابط موقعهم ويستغربون ليش ما يشتغل. - لما تنقل المنتج من رابط المعاينة لدومينك الخاص، أو تضيف
www، الرابط الجديد ما ينضاف لوحده في أي مكان. - الذكاء الاصطناعي يكتب الكود ويقول «أضف الرابط في Google Console»، والخطوة هذي تنسى، أو تنضاف لمشروع Google غلط، خصوصًا إذا عندك أكثر من مشروع.
ليش يرجع المستخدم على localhost
في Supabase فيه إعدادين في صفحة إعدادات الروابط (URL Configuration) تحت Authentication: Site URL، وهو الرابط الافتراضي اللي يرجع له المستخدم، وقائمة Redirect URLs المسموحة. إذا Site URL باقي http://localhost:3000 من أيام التجربة، أو رابط موقعك الحقيقي مو في القائمة المسموحة، Supabase يتجاهل الرابط اللي طلبه الكود ويرجّع المستخدم على Site URL. يعني على جهاز المطوّر، اللي ما يفتح عند أحد غيره.
كيف تتأكد بنفسك
- لما تطلع صفحة الخطأ من Google، اضغط على رابط تفاصيل الخطأ (error details) إذا ظهر. تلقى فيه قيمة
redirect_uriاللي أرسلها منتجك بالضبط. - افتح Google Cloud Console، ثم Google Auth Platform، ثم Clients، واختار عميل OAuth اللي يستخدمه منتجك، وقارن الرابط بقائمة Authorized redirect URIs حرف بحرف.
- إذا الدخول عن طريق Supabase، افتح إعدادات Authentication في مشروع Supabase، وتأكد إن Site URL هو دومينك الحقيقي، وإن روابط موقعك موجودة في Redirect URLs.
- تأكد إن Client ID اللي في Supabase أو في إعدادات منتجك هو نفس العميل اللي عدّلته في Google. تعديل صح في المكان الغلط يضيّع ساعات.
ملاحظة: إذا الخطأ اللي يطلع Error 403: access_denied لمستخدمين من برّا فريقك، غالبًا التطبيق في Google لسا في وضع Testing (تلقاه في Google Auth Platform تحت Audience)، اللي يسمح فقط للحسابات المضافة كمختبرين. هذي مشكلة ثانية، وحلها نشر التطبيق، وإذا يطلب صلاحيات حساسة يحتاج مراجعة من Google.
الحل اللي لا تسويه
لما يطوّل الموضوع، ممكن الذكاء الاصطناعي يقترح تضيف رابط عام بعلامة نجمة في قائمة Supabase، مثل https://*.vercel.app/**، عشان «أي رابط يشتغل». هذا يفتح باب: أي أحد ينشر موقع على نفس الاستضافة يقدر يستقبل جلسات دخول مستخدميك. القائمة المسموحة فيها روابطك أنت فقط: دومينك، ورابط المعاينة إذا تحتاجه، و localhost في بيئة التجربة فقط.
الحل الصح
- رابط واضح لكل بيئة: دومينك الحقيقي في الإنتاج، ورابط التجربة في بيئة التجربة، وكل واحد مسجّل في مكانه في Google وفي Supabase.
- الكود ما يكتب رابط الرجوع ثابت داخل الملفات. ياخذه من إعدادات البيئة أو من رابط الصفحة الحالية، عشان ما يرجع
localhostفي النسخة المنشورة. - بعد أي تغيير في الدومين، جرّب الدخول من نافذة خاصة (Incognito) ومن جوال، مو من جهازك اللي مسجّل دخول من قبل.
وإذا الدخول نفسه يشتغل وتبي تتأكد إن كل مستخدم ما يشوف إلا بياناته بعد ما يدخل، شوف 5 ثغرات في تسجيل الدخول.
علقت؟
هذي المشكلة غالبًا تنحل بسرعة لما مهندس يشوف الإعدادات معك. في مكالمة استشارية نشارك الشاشة ونصلّحها، وتعرف بالضبط إيش تغيّر وليش. لا تعطي أحد كلمة سر حساب Google أو Supabase: شوف كيف تعطي مبرمج صلاحية بدون كلمة السر. وإذا منتجك على Lovable، شوف مشاكل Lovable الأشهر.