Okul.com.tr — Eğitim Ekosistemi

Customer login has extra business rules — not interchangeable with user login

2 dakika okuma süresi

Proje: Okul Platform

Customer login ≠ user login — extra business rules on customer side

Regular user login (Front\UserController@login at /giris-yap) and customer login (Customer\UserController@login at the customer subdomain /giris-yap) look similar on the surface (both take login + password, call Auth::attempt), but customer login enforces extra rules that generic login skips.

Customer-only post-auth checks / side effects

Located in app/Http/Controllers/Customer/UserController.php::login:

  1. School access gating: Load $user->customer_user_schools and filter by has_lead_access || has_content_access. If empty → immediately AuthService::logout() and redirect to customer.login with error "Bu kullanıcıya ait okul bulunmamakta veya onay sürecindedir". A valid DB user without any approved school is NOT allowed to stay logged in on the customer panel.
  2. selected_customer_id session reset (session()->forget(...)) — forces re-selection of customer context after each login.
  3. Activity log with contentType: 'CustomerUsers' (vs 'Users' for regular login) — downstream analytics / audit depend on this distinction.
  4. MigrationService::handleUserLoggedIn($user) call — touches api-token / session bridging for customer panel calls (see also ApiSessionMigration middleware). Generic user login does NOT call this.
  5. Redirect to customer_homepage or redirect_url param (generic login uses url.intended).

Implication for PR 2000 (/api/auth/login, /api/auth/otp)

AuthService::login (school-api) is user-type-agnostic — Auth::loginUsingId($externalApiResponse->data->id) with no customer-specific validation. If a customer user’s credentials happen to be accepted by the external API:

  • Login “succeeds” technically
  • BUT the school access check is skipped — an unapproved/unlinked customer stays logged in
  • BUT CustomerUsers activity log is missing
  • BUT MigrationService isn’t invoked — subsequent customer-panel API calls may fail
  • BUT redirect goes wherever the FE decides, not customer_homepage

Rule

Do NOT reuse /api/auth/login or /api/auth/otp for customer login until BE adds customer-specific endpoints (or extends existing ones to detect customer type and run the full customer flow). The silent omissions above are regression-prone.

FE implication

If/when customer OTP gets added:

  • Separate FE integration needed for customer_v2/user/login.blade.php
  • Probably separate endpoints (e.g., /api/auth/customer/login, /api/auth/customer/otp) or a new parameter on existing endpoints
  • Error messaging must include the “okul bulunmamakta” case

Grafik Görünümü

Backlinkler