DEV Community: Munir Ahmad

Fix Microsoft 365 SMTP 535 5.7.3: Send Laravel Email with Microsoft Graph and Restrict It to One Mailbox

Munir Ahmad — Thu, 08 Oct 2026 18:13:46 +0000

A step-by-step guide for developers who are not Exchange admins: stop using a mailbox password, send through the Graph API, and restrict the app to a single mailbox with Exchange RBAC for Applications.

Last verified: October 2026. Microsoft’s admin portals change often, so check menu names against the current docs if something looks different.

TL;DR

If your Laravel app sends mail through smtp.office365.com and fails with 535 5.7.3 Authentication unsuccessful, you have two options:

Quick fix(not recommended for production): turn off Security Defaults in Microsoft Entra. This fixed my login, but it removes MFA enforcement and legacy sign-in blocking for your whole tenant.
Right fix (this article): stop using a mailbox password. Send through the Microsoft Graph API with an app that can only send as one shared mailbox (noreply@yourdomain.com), using a small custom Laravel mail transport. Your existing Mailables and Notifications work unchanged.

By the end you will have:

a dedicated noreply@yourdomain.com shared mailbox,
an Entra app that can send only as that mailbox,
a Laravel graph mailer that works with all your existing Mailables, Notifications and queues, with no code changes in them.

I did this on a real project, hit every wall, and wrote down the fixes.

1. The problem

My Laravel API sent verification emails through Microsoft 365 over SMTP. Then this happened:

> AUTH LOGIN
< 334 VXNlcm5hbWU6
> …
< 535 5.7.3 Authentication unsuccessful
curl: (67) Login denied

I reproduced it outside Laravel with plain curl so I could rule out my app:

curl -v \
  --url "smtp://$SMTP_HOST:$SMTP_PORT" \
  --ssl-reqd \
  --user "$SMTP_USERNAME:$SMTP_PASSWORD" \
  --mail-from "$MAIL_FROM" \
  --mail-rcpt "$MAIL_TO" \
  --upload-file <(printf 'From: %s\r\nTo: %s\r\nSubject: SMTP Test\r\n\r\nTest.\r\n' "$MAIL_FROM" "$MAIL_TO")

The connection and TLS were fine. Microsoft simply refused the login, so the network and port 587 were not the problem.

2. Why Microsoft rejects the login

Microsoft’s SMTP AUTH documentation lists three things that block SMTP AUTH even when your credentials are correct:

Security Defaults is on. SMTP AUTH is already disabled, and mailbox settings don’t override it.
SMTP AUTH is switched off for the organization or the mailbox. The mailbox setting wins over the organization one.
An authentication policy blocks Basic authentication for SMTP.

Security Defaults is a free bundle of tenant-wide protections from Microsoft: MFA registration, MFA for admins, and blocking of legacy authentication, which includes SMTP, IMAP and POP3. That last rule stops an app from logging in with a username and password. The switch is under Entra ID → Overview → Properties → Manage security defaults.

What fixed it for me: turning Security Defaults off. Nothing else changed, and I never switched SMTP AUTH on myself. Afterwards I ran this check on my mailbox:

Get-CASMailbox -Identity <mailbox> | Format-List SmtpClientAuthenticationDisabled

It returned False, which means SMTP AUTH is enabled for that mailbox. Run it on yours instead of assuming.

Why it’s only a bridge. Turning Security Defaults off removes MFA enforcement and legacy sign-in blocking for your whole tenant. Microsoft’s advice is to replace them with Conditional Access. And under its updated timeline, SMTP Basic authentication will be disabled by default for existing tenants at the end of December 2026. Admins can still turn it back on, and the final removal date will be announced in the second half of 2027. These dates have moved before, so check the page again before you deploy.

3. The better design

Instead of logging in as a person, your app gets its own identity: a client ID and a client secret. It trades them for a short-lived token and sends mail through the Microsoft Graph sendMail API.

Laravel Queue Worker
        │
        │ 1. client_id + client_secret
        ▼
Microsoft Entra ID
        │
        │ 2. access token
        ▼
Microsoft Graph
        │
        │ 3. POST /users/noreply@yourdomain.com/sendMail
        │ Authorization: Bearer <token>
        ▼
Exchange Online
        │
        │ Exchange RBAC
        │ ┌─────────────────────────────┐
        └──► noreply@yourdomain.com ONLY
           └─────────────────────────────┘
        │
        ▼
Recipient

Why this is better:

No mailbox password in your .env. The secret expires, and you can rotate it without touching any mailbox.
No SMTP, so Security Defaults can stay on. Graph doesn’t use SMTP AUTH, and I re-ran the test with Security Defaults enabled: it still returned 202 Accepted.
It can be locked to one mailbox. This is the part most tutorials skip.

The mistake most tutorials make

The usual route is to add the Microsoft Graph Mail.Send application permission in Entra and grant admin consent. It works, but that permission lets the app send mail as any user in your organization. If the client secret leaks, someone can send email as your CEO.

Microsoft’s fix is RBAC for Applications in Exchange Online, which replaces the older Application Access Policies. You grant the send permission inside Exchange, limited to the mailboxes you choose.

One rule: don’t also grant Mail.Send in Entra. Microsoft's FAQ says the two grants add up, so an unscoped Entra grant cancels your restriction. This guide adds no API permissions in Entra.

4. Prerequisites

A Microsoft 365 tenant with Exchange Online, and an admin account. A Global Administrator covers everything in this guide. Microsoft’s RBAC for Applications article lists the minimum roles if you want a narrower account. If your tenant came through a reseller such as GoDaddy, see the note in Step 1.
A Laravel app. I tested on Laravel 11. It should work on any version that uses Symfony Mailer (Laravel 9 and newer), but I haven’t tried them, so run the included test on yours.
PowerShell 7 on a Mac, Linux or Windows machine. Microsoft documents the mailbox-restriction step only in PowerShell, so you need it once.

5. Step by step

Step 1: Create the sending mailbox

Use a shared mailbox. Nobody can sign in to it with a password, so there is nothing to leak, and basic shared mailboxes don’t need their own license.

Open the Exchange admin center: https://admin.cloud.microsoft/exchange
Go to Recipients → Mailboxes → Add a shared mailbox.
Display name: your brand name, for example Your Brand. Recipients usually see this as the sender name.
Email address: noreply, then pick your primary domain from the dropdown (for example yourdomain.com).
Alias: leave it blank.
Create it. It may take a few minutes to appear.

Reseller tenants (GoDaddy etc.): In my tenant the “Microsoft 365 admin center” link inside the Exchange admin center redirected to GoDaddy. You don’t need it. Everything in this guide uses the Exchange admin center, the Entra admin center and PowerShell.

Step 2: Register the app in Microsoft Entra

Go to https://entra.microsoft.com → Entra ID → App registrations → New registration.
Name: your-app-mailer. It's a label for admins, not the sender name.
Supported account types: Single tenant only.
Redirect URI: leave empty.
Click Register.
On the Overview page, copy the Application (client) ID and the Directory (tenant) ID.

Go to Certificates & secrets → Client secrets → New client secret. Add a description and choose an expiry. Microsoft recommends less than 12 months, so I use 6. Click Add.
Copy the Value immediately. Microsoft never shows it again once you leave the page.

Pitfall: There are two columns, Value and Secret ID. You need Value. The Secret ID is just a label, and using it gives you an invalid-client error.

A note on secrets in production: Microsoft says client secrets are less secure than certificates and recommends certificates for production applications. A secret is the simplest way to get started, and in this guide the damage a leaked secret can do is limited to one mailbox (Step 4). If your security requirements are stricter, switch to a certificate once this works.

Do not open “API permissions” and add anything. The permission comes from Exchange in Step 4.

Step 3: Get the Enterprise App Object ID

Exchange needs the object ID of the app’s service principal , which is not the Object ID shown on the App registrations page.

In Entra, go to Entra ID → Enterprise apps and click your app.
Copy the Object ID.

Microsoft’s docs call this out explicitly: the Object ID on the App registrations page is a different value. Using the wrong one is the easiest mistake in this whole process.

Step 4: Restrict the app to one mailbox (PowerShell)

This step limits what the app is allowed to do. Microsoft documents it in PowerShell, so install that first. The steps below are for macOS.

Install PowerShell 7

Download the signed .pkg for your Mac from Microsoft's PowerShell releases page (osx-arm64 for Apple silicon, osx-x64 for Intel), then double-click it. This is the method Microsoft recommends.

To check the download is genuine (your file name will differ):

pkgutil --check-signature powershell-7.x.x-osx-x64.pkg

Look for Developer ID Installer: Microsoft Corporation and Notarization: trusted by the Apple notary service.

Homebrew works too (brew install — cask powershell), but Microsoft lists it as a third-party method.

Start PowerShell and connect to Exchange Online:

pwsh

Install-Module ExchangeOnlineManagement -Scope CurrentUser
Connect-ExchangeOnline

A browser window opens. Sign in with your admin account.

First, prove your filter matches exactly one mailbox:

Get-Mailbox -RecipientTypeDetails SharedMailbox `
  -Filter "PrimarySmtpAddress -eq 'noreply@yourdomain.com'" |
  Format-Table Name,PrimarySmtpAddress

You must see exactly one row: your noreply@ mailbox. If you see none or several, stop and fix the filter.

Then create the scope and the role assignment. These commands follow Microsoft’s RBAC for Applications documentation:

# 1. Tell Exchange about the Entra service principal
New-ServicePrincipal -AppId <APPLICATION_CLIENT_ID> `
  -ObjectId <ENTERPRISE_APP_OBJECT_ID> `
  -DisplayName "your-app-mailer"

# 2. Define the set of mailboxes the app may touch
New-ManagementScope -Name "NoReplyOnly" `
  -RecipientRestrictionFilter "PrimarySmtpAddress -eq 'noreply@yourdomain.com'"
# 3. Grant "send mail" only within that scope
New-ManagementRoleAssignment -App <ENTERPRISE_APP_OBJECT_ID> `
  -Role "Application Mail.Send" `
  -CustomResourceScope "NoReplyOnly"

Verify with Microsoft’s test cmdlet. Check the allowed mailbox and a mailbox that should be blocked:

Test-ServicePrincipalAuthorization -Identity <ENTERPRISE_APP_OBJECT_ID> -Resource noreply@yourdomain.com | Format-Table
Test-ServicePrincipalAuthorization -Identity <ENTERPRISE_APP_OBJECT_ID> -Resource someone-else@yourdomain.com | Format-Table

Here is what mine returned:

RoleName GrantedPermissions AllowedResourceScope ScopeType InScope
-------- ------------------ -------------------- --------- -------
Application Mail.Send Mail.Send NoReplyOnly CustomRecipientScope True ← noreply@
Application Mail.Send Mail.Send NoReplyOnly CustomRecipientScope False ← another mailbox

True for the shared mailbox, False for everyone else.

Disconnect when you are done:

Disconnect-ExchangeOnline -Confirm:$false

Propagation delay: Microsoft says permission changes can take roughly 30 minutes to 2 hours to take effect, depending on how recently the app was used. The test command above bypasses that delay, but real API calls don’t. If your first send fails with a 403, wait before you debug.

Step 5: Test the send with curl before touching Laravel

Always test the Microsoft side in isolation first. Set the values in your shell. In zsh, read -s keeps the secret out of your shell history and screen:

export TENANT_ID='<directory (tenant) id>'
export CLIENT_ID='<application (client) id>'

# zsh (default on macOS):
read -s "CLIENT_SECRET?Secret value: " && export CLIENT_SECRET

# bash (most Linux):
read -s -p "Secret value: " CLIENT_SECRET && export CLIENT_SECRET

Get an access token (the client-credentials flow):

TOKEN=$(curl -s -X POST "https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token" \
  -d "client_id=$CLIENT_ID" -d "client_secret=$CLIENT_SECRET" \
  -d "scope=https://graph.microsoft.com/.default" -d "grant_type=client_credentials" \
  | python3 -c "import sys,json;print(json.load(sys.stdin).get('access_token','FAILED'))")
echo ${TOKEN:0:20}

You should see about 20 characters of a token. If the command crashes or prints FAILED, one of the three variables is empty or wrong. Check them with:

echo "[$TENANT_ID]" "[$CLIENT_ID]" ${#CLIENT_SECRET}

Send an email:

curl -i -X POST "https://graph.microsoft.com/v1.0/users/noreply@yourdomain.com/sendMail" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"message":{"subject":"Graph test","body":{"contentType":"Text","content":"It works."},"toRecipients":[{"emailAddress":{"address":"you@example.com"}}]}}'

Expected: HTTP/1.1 202 Accepted. Per Microsoft, 202 means the request was accepted. It doesn't guarantee delivery; delivery is still subject to Exchange Online limits and throttling.

6. Wiring it into Laravel

Laravel has no built-in Microsoft Graph mail driver, but it sends mail through Symfony Mailer, which accepts custom transports. The transport below takes the finished MIME message and posts it to Graph, so your existing Mailables and Notifications work without changes. Ready-made packages exist too, such as InnoGE/laravel-msgraph-mail and maize-tech/laravel-msgraph-mailer. I wrote a small one (under 70 lines) to avoid another dependency. The Microsoft setup is identical either way.

6.1 The transport

app/Mail/Transport/GraphTransport.php

<?php

namespace App\Mail\Transport;

use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\Http;
use Symfony\Component\Mailer\Exception\TransportException;
use Symfony\Component\Mailer\SentMessage;
use Symfony\Component\Mailer\Transport\AbstractTransport;

class GraphTransport extends AbstractTransport
{
    public function __construct(
        private readonly string $tenantId,
        private readonly string $clientId,
        private readonly string $clientSecret,
        private readonly string $sender,
    ) {
        parent::__construct();
    }

    protected function doSend(SentMessage $message): void
    {
        $response = Http::withToken($this->accessToken())
            ->withBody(base64_encode($message->toString()), 'text/plain')
            ->post("https://graph.microsoft.com/v1.0/users/{$this->sender}/sendMail");

        if ($response->status() !== 202) {
            throw new TransportException(
                "Microsoft Graph sendMail failed ({$response->status()}): ".$response->body()
            );
        }
    }

    private function accessToken(): string
    {
        return Cache::remember("graph-mail-token:{$this->clientId}", now()->addMinutes(50), function () {
            $response = Http::asForm()->post(
                "https://login.microsoftonline.com/{$this->tenantId}/oauth2/v2.0/token",
                [
                    'client_id' => $this->clientId,
                    'client_secret' => $this->clientSecret,
                    'scope' => 'https://graph.microsoft.com/.default',
                    'grant_type' => 'client_credentials',
                ]
            );

            if ($response->failed() || ! $response->json('access_token')) {
                throw new TransportException(
                    "Microsoft Graph token request failed ({$response->status()}): ".$response->body()
                );
            }

            return $response->json('access_token');
        });
    }

    public function __toString(): string
    {
        return 'graph';
    }
}

How it works:

Raw MIME in, 202 out. It posts the whole message base64-encoded, which is Graph's MIME mode. That's why attachments, headers and HTML/text versions survive. Graph answers 202 Accepted when it takes the message, and anything else becomes a TransportException, so Laravel reports a failed send instead of losing the email.
Token cache. Microsoft’s documentation says access tokens last a random 60–90 minutes by default, so a 50-minute cache always expires first.
Sender. The mailbox in the URL is the one Graph sends from. It must be the mailbox you scoped in Step 4.

6.2 Register the driver

app/Providers/AppServiceProvider.php

use App\Mail\Transport\GraphTransport;
use Illuminate\Support\Facades\Mail;

public function boot(): void
{
    Mail::extend('graph', fn (array $config) => new GraphTransport(
        $config['tenant_id'],
        $config['client_id'],
        $config['client_secret'],
        $config['sender'],
    ));
}

6.3 Add the mailer

In config/mail.php inside the mailers array:

'graph' => [
    'transport' => 'graph',
    'tenant_id' => env('MS_GRAPH_TENANT_ID'),
    'client_id' => env('MS_GRAPH_CLIENT_ID'),
    'client_secret' => env('MS_GRAPH_CLIENT_SECRET'),
    'sender' => env('MAIL_FROM_ADDRESS'),
],

6.4 Environment variables

MAIL_MAILER=graph
MAIL_FROM_ADDRESS=noreply@yourdomain.com
MAIL_FROM_NAME="${APP_NAME}"

MS_GRAPH_TENANT_ID=<directory (tenant) id>
MS_GRAPH_CLIENT_ID=<application (client) id>
MS_GRAPH_CLIENT_SECRET=<secret VALUE>

Remove the old MAIL_HOST, MAIL_PORT, MAIL_USERNAME, MAIL_PASSWORD and MAIL_ENCRYPTION lines. MAIL_FROM_ADDRESS must be the mailbox you scoped in Step 4. Add the three MS_GRAPH_* keys, empty, to .env.example, and keep real values in your host's secret store, never in git.

6.5 Apply the changes

Laravel’s queue workers read your configuration once, when they start. After editing mail settings, clear cached config and restart them:

php artisan config:clear
php artisan queue:restart # plain queue workers
php artisan horizon:terminate # if you use Horizon (your process manager restarts it)

Then confirm Laravel sees the new driver:

php artisan config:show mail.default # should print: graph

If mail still goes out the old way, look for a MAIL_* variable set outside .env (Docker Compose, your host's environment settings, a CI secret). Real environment variables win over .env.

Finally, send yourself a test:

php artisan tinker --execute="Mail::raw('Laravel Graph test', fn(\$m) => \$m->to('you@example.com')->subject('Laravel test'));"

7. Troubleshooting

Token request fails or returns nothing. Check TENANT_ID, CLIENT_ID and the secret for typos or empty values. Also check that you copied the secret's Value , not its Secret ID, and that the secret hasn't expired. Run the raw token request from Step 5 to see Microsoft's error message.
403 right after setup. Microsoft says permission changes can take roughly 30 minutes to 2 hours to apply. Wait before debugging.
403 that doesn't go away. Make sure you used the Enterprise app Object ID (Step 3) in the Step 4 commands, and that MAIL_FROM_ADDRESS is the mailbox you scoped.
The app can send as other mailboxes. You likely also granted Mail.Send under API permissions in Entra. Microsoft says the Entra grant and the Exchange grant add up, so remove it from Entra and keep only the Exchange one.
Emails still arrive from the old sender. Your workers are running old configuration. Run the commands in “Apply the changes” in section 6.
202 Accepted but nothing in the inbox. 202 only means Graph accepted the message. Check spam, run a message trace in the Exchange admin center, and make sure SPF, DKIM and DMARC are set up for your domain.

Fastlane for Flutter: Complete Local Setup for iOS and Android Deployments

Munir Ahmad — Mon, 14 Sep 2026 08:17:27 +0000

Stop manual store clicks. Learn how to configure Fastlane locally to build, guard, and ship your Flutter app to TestFlight and Google Play with a single command.

Why bother

Every Flutter release usually looks like this: bump the version, build the IPA, open Xcode, wait for the organizer, switch to browsers, build the AAB, drag-and-drop into the Play Console, and fill out release notes. It’s ten minutes of tedious clicking that changes every time, meaning it never becomes muscle memory.

Fastlane turns that entire ritual into:

bundle exec fastlane ios deploy 
bundle exec fastlane android deploy

This article is Part 1 : getting it working locally on your machine. Part 2 moves these exact lanes into GitHub Actions so a simple tag push handles the rest. Do this part first — the CI setup assumes your local lanes are already green.

What you’ll need

A Flutter app that already builds and runs
An Apple Developer account ($99/yr) with the app registered in App Store Connect
A Google Play Console account ($25 one-time) with the app created and at least one AAB uploaded manually — Play won’t accept the first-ever build over the API.
Ruby (macOS ships with one; a version manager like rbenv is nicer but not required)
Xcode with a valid signing setup for your app (Automatic signing with your team selected is fine for local)

I’m on FVM, so my Flutter SDK lives at /Users/<you>/fvm/versions/3.32.0. Note your own path now — you'll need it in a minute.

Step 1 — Install fastlane via a Gemfile (not globally)

You can brew install fastlane or gem install fastlane, but pinning it per-project with Bundler means your machine and your CI runner use the exact same version. Flutter projects have a ios/ and an android/ folder, and each gets its own Gemfile.

ios/Gemfile

source "https://rubygems.org"
gem "fastlane"
gem "cocoapods"

android/Gemfile

source "https://rubygems.org"
gem "fastlane"

The iOS Gemfile also pins CocoaPods so the build doesn’t depend on whatever pod version happens to be on the system (this matters a lot on CI later). Android has no such dependency, so its Gemfile stays minimal.

Install both:

cd ios && bundle install && cd ..
cd android && bundle install && cd ..

From here on, always call fastlane as bundle exec fastlane … so you get the pinned version.

Step 2 — Set FLUTTER_ROOT

fastlane’s iOS build scripts shell out to Flutter and need to know where the SDK is. Add this to your shell profile (~/.zshrc):

export FLUTTER_ROOT="/Users/<you>/fvm/versions/3.32.0"

If you’re not on FVM, it’s wherever which flutter points, minus /bin/flutter. Reload your shell (source ~/.zshrc) and confirm:

echo $FLUTTER_ROOT

Step 3 — Confirm the raw builds work

Before automating anything, make sure the two build commands fastlane will run actually succeed on their own:

fvm flutter build appbundle --release # Android -> build/app/outputs/bundle/release/app-release.aab

fvm flutter build ipa --release # iOS -> build/ios/ipa/<YourApp>.ipa

If flutter build ipa complains about signing, open ios/Runner.xcworkspace in Xcode once, select the Runner target → Signing & Capabilities, tick Automatically manage signing, pick your team, and let it create the profile. Then re-run. Don't move on until both commands produce an artifact.

Step 4 — `fastlane init` for iOS

# from app's root
cd ios
bundle exec fastlane init

Pick option 2 (Automate beta distribution to TestFlight). It parses your Xcode project, then asks you to log in with your Apple ID. This triggers a 2FA prompt on your trusted device — enter the 6-digit code. It’ll verify the app exists in both the Developer Portal and App Store Connect.

This creates ios/fastlane/Appfile and ios/fastlane/Fastfile.

Step 5 — `fastlane` init for Android

# from app's root
cd android
bundle exec fastlane init

It asks for your package name (must match applicationId in android/app/build.gradle), then asks for the path to a Play service account JSON. Press Enter to skip that for now — we'll wire it up properly in Step 6.

This creates android/fastlane/Appfile and android/fastlane/Fastfile.

Step 6 — Fill in the Appfiles

android/fastlane/Appfile

json_key_file("pc-key.json") # only used by validate/supply — the deploy lane uses the base64 env var
package_name("com.example.app") # must match applicationId in android/app/build.gradle

Now get the pc-key.json:

Open the Google Cloud APIs & Services page.
Enable the Google Play Android Developer API for that project.

Create the Service Account directly in Google Cloud

Open the Google Cloud IAM Service Accounts page.
Make sure you are logged into the Google account that manages this Play Store developer profile.
Select your Google Cloud project from the top dropdown (or create a quick project named “Play Store Fastlane” if none exists).
Click + CREATE SERVICE ACCOUNT at the top.
Enter fastlane-supply as the Service Account name and click DONE.
Copy the generated Service Account Email address (looks like fastlane-supply@your-project-id.iam.gserviceaccount.com).

Generate and download the JSON key:

Click on the newly created service account email in the list.
Click the Keys tab at the top.
Click ADD KEY > Create new key.
Choose JSON as the key type and click CREATE.
Save the downloaded .json file into your project's android/ directory as pc-key.json.

Grant access via Users and permissions:

Return to your Google Play Console tab.
Click Users and permissions from the left sidebar (the 3rd item from the top in your screenshot).
Click Invite new users at the top right.
Paste the Service Account Email you copied above into the email address field.
Under Account permissions , grant permissions for Release to testing tracks.
Click Invite user at the bottom right.

Verify the connection in Fastlane:

bundle exec fastlane run validate_play_store_json_key json_key:pc-key.json

Now base64-encode it into .env.deploy (this is what the lane actually uses, and the same value goes into GitHub Secrets later — one encoding, two homes):

base64 -i android/pc-key.json | tr -d '\n' | pbcopy
# paste into .env.deploy as: PLAY_STORE_JSON_KEY_BASE64=<pasted>

ios/fastlane/Appfile

app_identifier("com.example.app") # must match your bundle ID in Xcode
apple_id("you@example.com") # your Apple Developer account email
itc_team_id("1234567") # App Store Connect team ID
team_id("ABCDE12345") # Developer Portal team ID

If you don’t know the team IDs, run bundle exec fastlane spaceship or check the URLs in the App Store Connect / Developer portal — they're in there. These aren't secret, but people often redact them out of habit; your call.

Step 7 — iOS auth: use an App Store Connect API key, not your password

You’ll see guides that tell you to set FASTLANE_USER and FASTLANE_PASSWORD. Don't. With an Apple ID that has 2FA (all of them now do), that approach means:

constant 2FA prompts you can’t answer from a CI runner
sessions that expire every few days
the occasional locked account when Apple decides the login looks robotic

An App Store Connect API key sidesteps all of it — no 2FA, no expiry, and it’s scoped to just what it needs.

App Store Connect → Users and Access → Integrations → App Store Connect API.
Create a key with the App Manager role.
Download the AuthKey_XXXXXXXXXX.p8 — you can only download it once.
Note the Key ID and the Issuer ID shown on that page.

Encode the key and the two IDs into .env.deploy:

base64 -i AuthKey_XXXXXXXXXX.p8 | tr -d '\n' | pbcopy

# .env.deploy
APP_STORE_CONNECT_API_KEY_ID=XXXXXXXXXX
APP_STORE_CONNECT_API_ISSUER_ID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
APP_STORE_CONNECT_API_KEY_BASE64=<pasted>

Delete the downloaded .p8 once it's encoded — .env.deploy is now the only copy you keep, and it's gitignored. Apple only lets you download the .p8 once. If you lose it, revoke that key in App Store Connect and issue a new one.

Step 7B — the `.env.deploy` file

All deploy secrets live in foody-app/.env.deploy, which both Fastfiles load via dotenv at the top. It is gitignored; a committed .env.deploy.example documents every key. Your .gitignore should already have:

.env
.env.*
!.env.example
!.env.deploy.example
android/pc-key.json

.env.deploy.example also lists BUILD_CERTIFICATE_BASE64, P12_PASSWORD, BUILD_PROVISION_PROFILE_BASE64, KEYCHAIN_PASSWORD, APPLE_TEAM_ID — those are only for CI signing (Part 2). Locally, Xcode's managed signing handles it and you can leave them blank.

Step 8 — Write the deploy lanes

Replace the generated Fastfile in each folder with these.

fastlane init generates a placeholder Fastfile. Replace each with the version below. They share the same shape: load .env.deploy, check the store first , build with fvm flutter, upload.

android/fastlane/Fastfile

default_platform(:android)

require "dotenv"
deploy_env = File.expand_path("../../.env.deploy", __dir__ || File.dirname( __FILE__ ))
Dotenv.load(deploy_env) if File.exist?(deploy_env)

platform :android do
  desc "Automated build & deploy to Play Store Internal Track"
  lane :deploy do
    json_key_data = play_json_key_data
    guard_version_code_is_new(json_key_data)

    UI.message("🚀 Building Android App Bundle")

    Bundler.with_unbundled_env do
      sh("cd ../.. && fvm flutter build appbundle --release")
    end

    upload_build(json_key_data: json_key_data)
  end

  desc "Upload the already-built AAB to Play Console (skips Flutter build)"
  lane :upload do
    json_key_data = play_json_key_data
    guard_version_code_is_new(json_key_data)
    upload_build(json_key_data: json_key_data)
  end

  private_lane :upload_build do |options|
    app_root = File.expand_path("../..", __dir__ || File.dirname( __FILE__ ))
    aab_path = File.join(app_root, "build/app/outputs/bundle/release/app-release.aab")

    UI.user_error!("No .aab found at #{aab_path} — run `fastlane android deploy` or `flutter build appbundle` first") unless File.exist?(aab_path)

    upload_to_play_store(
      json_key_data: options[:json_key_data],
      track: "internal",
      aab: aab_path,
      skip_upload_metadata: true,
      skip_upload_images: true,
      skip_upload_screenshots: true
    )
  end
end

def play_json_key_data
  b64 = ENV["PLAY_STORE_JSON_KEY_BASE64"].to_s
  UI.user_error!("PLAY_STORE_JSON_KEY_BASE64 missing from foody-app/.env.deploy") if b64.empty?
  require "base64"
  Base64.decode64(b64)
end

def pubspec_version
  pubspec = File.expand_path("../../pubspec.yaml", __dir__ || File.dirname( __FILE__ ))
  m = File.read(pubspec).match(/^version:\s*(\d+\.\d+\.\d+)\+(\d+)/)
  UI.user_error!("Could not read version from pubspec.yaml") unless m
  [m[1], m[2].to_i]
end

def guard_version_code_is_new(json_key_data)
  _, local = pubspec_version
  package = CredentialsManager::AppfileConfig.try_fetch_value(:package_name)

  seen = %w[production internal].flat_map do |track|
    begin
      google_play_track_version_codes(package_name: package, track: track, json_key_data: json_key_data)
    rescue => e
      UI.important("Could not read Play '#{track}' track (#{e.message})")
      []
    end
  end.map(&:to_i)

  max_live = (seen + [0]).max
  if local <= max_live
    UI.user_error!("pubspec versionCode #{local} is not ahead of Play's #{max_live} — run `cider bump build` first.")
  end
  UI.success("pubspec versionCode #{local} is ahead of Play (#{max_live}) ✓")
end

ios/fastlane/Fastfile

default_platform(:ios)

require "dotenv"
deploy_env = File.expand_path("../../.env.deploy", __dir__ || File.dirname( __FILE__ ))
Dotenv.load(deploy_env) if File.exist?(deploy_env)

platform :ios do
  desc "Build IPA and upload to TestFlight"
  lane :deploy do
    api_key = app_store_api_key
    guard_build_number_is_new(api_key)

    Bundler.with_unbundled_env do
      sh("cd .. && fvm flutter build ipa --release")
    end
    upload_build(api_key: api_key)
  end

  desc "Upload the already-built IPA to TestFlight (skips the Flutter build)"
  lane :upload do
    api_key = app_store_api_key
    guard_build_number_is_new(api_key)
    upload_build(api_key: api_key)
  end

  private_lane :upload_build do |options|
    app_root = File.expand_path("../..", __dir__ || File.dirname( __FILE__ ))
    ipa_path = Dir[File.join(app_root, "build/ios/ipa/*.ipa")].max_by { |f| File.mtime(f) }
    UI.user_error!("No .ipa found under #{app_root}/build/ios/ipa — run `fastlane ios deploy` or `flutter build ipa` first") unless ipa_path

    upload_to_testflight(
      api_key: options[:api_key],
      ipa: ipa_path,
      skip_waiting_for_build_processing: true,
      skip_submission: true
    )
  end
end

def app_store_api_key
  key_id = ENV["APP_STORE_CONNECT_API_KEY_ID"].to_s
  issuer_id = ENV["APP_STORE_CONNECT_API_ISSUER_ID"].to_s
  key_b64 = ENV["APP_STORE_CONNECT_API_KEY_BASE64"].to_s

  UI.user_error!("APP_STORE_CONNECT_API_KEY_ID missing from foody-app/.env.deploy") if key_id.empty?
  UI.user_error!("APP_STORE_CONNECT_API_ISSUER_ID missing from foody-app/.env.deploy") if issuer_id.empty?
  UI.user_error!("APP_STORE_CONNECT_API_KEY_BASE64 missing from foody-app/.env.deploy") if key_b64.empty?

  app_store_connect_api_key(
    key_id: key_id,
    issuer_id: issuer_id,
    key_content: key_b64,
    is_key_content_base64: true,
    in_house: false
  )
end

def pubspec_version
  pubspec = File.expand_path("../../pubspec.yaml", __dir__ || File.dirname( __FILE__ ))
  m = File.read(pubspec).match(/^version:\s*(\d+\.\d+\.\d+)\+(\d+)/)
  UI.user_error!("Could not read version from pubspec.yaml") unless m
  [m[1], m[2].to_i]
end

# Fail before the ~10-minute build if pubspec's +N was not bumped past what
# TestFlight already has for this marketing version.
def guard_build_number_is_new(api_key)
  name, local = pubspec_version
  begin
    live = latest_testflight_build_number(
      api_key: api_key,
      app_identifier: CredentialsManager::AppfileConfig.try_fetch_value(:app_identifier),
      version: name,
      initial_build_number: 0
    ).to_i
  rescue => e
    UI.error("Could not check TestFlight build numbers (#{e.message}) — skipping the guard; the store will still reject a reused build.")
    return
  end

  if local <= live
    UI.user_error!("pubspec build #{name}+#{local} is not ahead of TestFlight's #{live} — run `cider bump build` first.")
  end
  UI.success("pubspec #{name}+#{local} is ahead of TestFlight (#{live}) ✓")
end

.env.deploy at the top . Both files load it with dotenv before anything runs. On CI the same variables come from the environment, so the Fastfile doesn't change.
The guard_* check runs first, and hits the store API, not a build. flutter build ipa takes ~10 minutes. If you forgot to bump the version, the guard catches it in a couple of seconds — iOS asks TestFlight for the latest build number of the current marketing version; Android asks Play for the highest versionCode across the production and internal tracks. If your pubspec.yaml isn't ahead, it stops with "run cider bump build first."
app_store_api_key / play_json_key_data decode the base64 secret in memory. Nothing is ever written to disk.
Two lanes. deploy = build + upload. upload = upload the artifact that's already in build/, skipping the build — for when the upload failed and you don't want to wait 10 minutes again.
Bundler.with_unbundled_env { sh("… fvm flutter build …") } runs the Flutter build outside fastlane's Bundler context so Flutter/CocoaPods resolve against FVM cleanly.
iOS picks the newest build/ios/ipa/*.ipa by modified time rather than guessing the filename from the app's display name. It uploads with skip_submission (goes to TestFlight, not the App Store review queue) and skip_waiting_for_build_processing (don't block the terminal while Apple processes it).
Android uploads to the internal track and skips metadata/images/screenshots so the lane only touches the binary.

Step 9 — Bump the version and Changelog

Play and TestFlight both reject a build number that already exists. pubspec.yaml’s version: line — X.Y.Z+N — is the single source of truth for both the iOS CFBundleVersion and the Android versionCode, and +N is the value both stores check for uniqueness:

version: 1.0.0+1 # <marketing version> + <build number>

This project manages the version with cider, added as a dev-dependency:

dev_dependencies:
  cider: ^0.2.10

It’s a dependency, not a global tool, so run it through the SDK: fvm dart run cider …

While you work: log changes

cider collects entries under an ## Unreleased heading in CHANGELOG.md:

fvm dart run cider log added "Dark mode toggle in settings."
fvm dart run cider log fixed "Crash when opening an expired invite link."

(log subcommands: added, changed, deprecated, fixed, removed, security.)

At release time: bump once, then release

Step 1 — bump the version. Run one of these, never both:

fvm dart run cider bump build # same version, next build: 1.0.0+1 -> 1.0.0+2
fvm dart run cider bump patch --bump-build # new marketing version: 1.0.0+1 -> 1.0.1+2

minor and major work the same way:

cider bump minor --bump-build
cider bump major --bump-build

Always pass --bump-build on a marketing bump. A plain cider bump patch drops the +N build number, and Play Console rejects any upload whose versionCode isn’t higher than the last one shipped. To set a version explicitly:

fvm dart run cider version 1.4.0+37.

Step 2 — stamp the changelog:

fvm dart run cider release

cider release turns ##Unreleased into a dated heading. After cider bump build (->1.0.0+2) and the two log entries above, CHANGELOG.md becomes:

## 1.0.0+2 - 2026-09-10
### Added
- Dark mode toggle in settings.

### Fixed
- Crash when opening an expired invite link.

Commit just those two files and tag — the tag is what Part 2’s CI triggers on:

git add pubspec.yaml CHANGELOG.md
git commit -m "chore(release): v1.0.0+2"
git tag -a v1.0.0+2 -m "v1.0.0+2"
git push --follow-tags

Do this once per release, from a clean tree, then deploy both platforms from that commit.

Step 10 — Ship it

# from app's root
cd android && bundle exec fastlane deploy && cd ..
cd ios && bundle exec fastlane deploy && cd ..

Both lanes read foody-app/.env.deploy. If a build fails at upload, rerun just bundle exec fastlane <platform> upload — it skips the 10-minute rebuild.

Troubleshooting the first run

flutter or fvm: command not found inside a lane: Ensure FVM is added to your shell's PATH where you launch Fastlane.
invalid curve name / .p8 key errors: Your Base64-encoded key string contains hidden line breaks. Re-encode it cleanly:

base64 -i key.p8 | tr -d '\n'

versionCode N is not ahead of Play's M: You skipped the version bump step. Run fvm dart run cider bump patch --bump-build, commit, and retry.
*_missing from .env.deploy errors: Fastlane cannot locate your environment file. Ensure .env.deploy sits directly at your app's root directory (foody-app/.env.deploy), not inside ios/ or android/.

What’s next — Part 2

Part 2 moves this exact workflow to GitHub Actions. Because every secret is already a base64 string in .env.deploy, CI is mostly “same variables, sourced from GitHub Secrets instead of the file.” The additions are: the iOS signing vars from .env.deploy.example (BUILD_CERTIFICATE_BASE64, P12_PASSWORD, BUILD_PROVISION_PROFILE_BASE64, KEYCHAIN_PASSWORD), a step that builds a throwaway keychain on the runner, and a workflow triggered by the v* tag you push in Step 9. The Fastfiles don't change at all.

Ten minutes of tedious web console clicking are now permanently replaced by a single command. Your local release pipeline is fully automated, version-guarded, and bulletproof.

Up next in Part 2 , we’ll take these exact lanes, move them to the cloud, and wire them up to GitHub Actions so a simple tag push handles the rest. Let’s ship code faster! 🚀

Use Multiple GitHub Accounts on One Machine (SSH)

Munir Ahmad — Sun, 14 Dec 2025 15:01:47 +0000

A step-by-step guide to seamlessly manage multiple GitHub accounts with SSH keys.

Managing Multiple GitHub Accounts on One Machine Using SSH

If you use both personal and work GitHub accounts on the same machine, authentication issues are almost inevitable. Commits go to the wrong account, pushes fail, or Git keeps asking for credentials.

The clean solution is simple: one SSH key per account, configured once, and reused forever. This guide shows how to do exactly that.

What You’ll Learn

Create separate SSH keys for each GitHub account
Configure SSH to automatically select the correct identity
Clone, push, and commit without account conflicts

Applies to: macOS and Linux (Windows users via WSL or Git Bash can follow the same steps)

Prerequisites

Git installed
Basic terminal knowledge
Access to multiple GitHub accounts

Step 1: Generate a Dedicated SSH Key

Create a new key for your work account:

ssh-keygen -t ed25519 -C "work@email.com" -f ~/.ssh/id_ed25519_work

This avoids overwriting existing keys and clearly separates identities.

When prompted, adding a passphrase is recommended for security.

Generated files:

id_ed25519_work — private key (keep secret)
id_ed25519_work.pub — public key (add to GitHub)

Step 2: Add the Key to the SSH Agent

Start the agent and load your key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_work

This allows Git to authenticate without repeatedly asking for a passphrase.

Step 3: Add the Public Key to GitHub

Copy your public key:

cat ~/.ssh/id_ed25519_work.pub

Copy the entire output (starts with ssh-ed25519).

Navigate to: https://github.com/settings/keys
Click New SSH key
Add a title (e.g., “Work Laptop — 2024”)
Paste your public key
Click Add SSH key

Highlighting where to add your SSH key in GitHub settings.

Step 4: Configure SSH Host Aliases

Edit your SSH config:

nano ~/.ssh/config

Add:

# Here you can add multiple identities personal, work etc.
# Personal account
Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

# Work account
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work
  IdentitiesOnly yes

This tells SSH exactly which key to use for each account.

Step 5: Test the Setup

ssh -T github-work

If successful, GitHub will confirm authentication. Expected output:

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

Using the Correct Account

Clone Repositories

# Work account
git clone git@github-work:company/repo.git

# Personal account
git clone git@github.com:username/repo.git

Fix an Existing Repository

git remote set-url origin git@github-work:company/repo.git

Set Commit Identity (Per Repository)

git config user.name "Your Name"
git config user.email "work@company.com"

This ensures commits are attributed correctly.

Final Thoughts

Managing multiple GitHub accounts doesn’t require hacks or workarounds.

With one SSH key per account and a clear SSH configuration , Git becomes invisible — and that’s exactly how tooling should behave.

Configure it once. Forget about it forever.

Secure Swagger & ReDoc in Django REST Framework with DRF Spectacular: Best Practices for API…

Munir Ahmad — Sun, 07 Dec 2025 17:56:18 +0000

Secure Swagger & ReDoc in Django REST Framework with DRF Spectacular: Best Practices for API Security

API documentation tools like Swagger UI and ReDoc make development easier, but they also expose every endpoint, schema, and request structure to anyone who can access the URL.

If you deploy your Django REST Framework project without protecting /api/docs/ or /api/schema/, you're unintentionally giving outsiders:

A complete map of all your APIs
All request/response structures
Authentication patterns
Internal admin/debug endpoints

This makes exploitation easier and increases your attack surface.

That’s why Swagger must never be public in production. In this guide, we’ll show a clean, secure way to protect your API documentation using DRF Spectacular in a Django REST Framework project.

A secure architecture for safeguarding Swagger and ReDoc in DRF using DRF Spectacular.

# Directory structure
core/
    docs/
        swagger_view.py
    urls.py
    settings.py

core/docs/swagger_view.py

from django.shortcuts import redirect
from drf_spectacular.views import (
    SpectacularAPIView,
    SpectacularSwaggerView,
    SpectacularRedocView,
)

class AdminOnlyMixin:
    """
    Restrict access to authenticated superusers.
    """

    def dispatch(self, request, *args, **kwargs):
        if not request.user.is_authenticated:
            return redirect(f"/admin/login/?next={request.path}")
        if not request.user.is_superuser:
            return redirect("/403/") # Make sure a 403 page exists
        return super().dispatch(request, *args, **kwargs)

class SuperuserSchemaView(AdminOnlyMixin, SpectacularAPIView):
    pass

class SuperuserSwaggerView(AdminOnlyMixin, SpectacularSwaggerView):
    pass

class SuperuserRedocView(AdminOnlyMixin, SpectacularRedocView):
    pass

core/urls.y

from django.urls import path
from core.docs import (
    SuperuserRedocView,
    SuperuserSchemaView,
    SuperuserSwaggerView,
)

urlpatterns = [
    # API documentation (protected)
    path("api/schema/", SuperuserSchemaView.as_view(), name="schema"),
    path("api/docs/", SuperuserSwaggerView.as_view(url_name="schema"), name="swagger-ui"),
    path("api/redoc/", SuperuserRedocView.as_view(url_name="schema"), name="redoc"),
]

core/settings.py

REST_FRAMEWORK = {
    "DEFAULT_AUTHENTICATION_CLASSES": (
        # JWT for external API clients
        "rest_framework_simplejwt.authentication.JWTAuthentication",

        # Session auth so Swagger works automatically after admin login
        "rest_framework.authentication.SessionAuthentication",
    ),
    "DEFAULT_PERMISSION_CLASSES": (
        "rest_framework.permissions.IsAuthenticated",
    ),
    "DEFAULT_SCHEMA_CLASS": "drf_spectacular.openapi.AutoSchema",
}

SPECTACULAR_SETTINGS = {
    "TITLE": "Your API",
    "DESCRIPTION": "API documentation",
    "VERSION": "1.0.0",

    # Allow our custom view to control permissions manually
    "SERVE_PERMISSIONS": ["rest_framework.permissions.IsAdminUser"],

    # Use DRF’s normal authentication classes (Session + JWT)
    "SERVE_AUTHENTICATION": None,

    # Important: Do NOT expose schema automatically in unrestricted mode
    "SERVE_INCLUDE_SCHEMA": False,
}

Notes:

SessionAuthentication allows admin users to access protected docs easily.
SERVE_INCLUDE_SCHEMA = False ensures your schema isn’t automatically exposed.

And that’s the real value of securing your API documentation: you empower your team without empowering your attackers. When Swagger and ReDoc live behind proper authentication, your developers gain clarity, your system gains integrity, and your attack surface quietly shrinks. Secure the docs, protect the blueprint, and let your API evolve with confidence — exactly the way production-grade engineering should be. Appreciate your time. Until next time 👋.

Install the Latest PostgreSQL (psql 18) on Ubuntu 24.04 (Noble)

Munir Ahmad — Mon, 03 Nov 2025 17:40:16 +0000

Why I Wrote This

While setting up my development environment on Ubuntu 24.04 (Noble Numbat), I noticed the default PostgreSQL version in Ubuntu’s repository was outdated.

So I decided to document the clean, official way to install the latest PostgreSQL (v18) — straight from the PostgreSQL Apt repository.

If you’ve ever run into issues like:

“No cluster suitable as a default target”
or old versions like PostgreSQL 14 or 15 being installed instead of the latest then this guide will help you start fresh.

Step-by-Step Guide to Installing PostgreSQL 18

Step 1 — Update and Upgrade Your System

sudo apt update && sudo apt upgrade -y

Step 2 — Check Your Ubuntu Codename:

PostgreSQL’s official repo depends on your Ubuntu version codename.

Run the following to check yours:

. /etc/os-release
echo $VERSION_CODENAME

For Ubuntu 24.04, the output should be:

noble

Step 3 — Install Required Packages

We’ll install curl, ca-certificates, and postgresql-common:

sudo apt install -y curl ca-certificates postgresql-common

Step 4 — Add the PostgreSQL Apt Repository

Run the following command to automatically add the official PostgreSQL repository:

sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh

Step 5 — Update Package Lists & Install PostgreSQL 18

sudo apt update
sudo apt install -y postgresql-18

When prompted during installation:

Type Y to confirm.
If you see a purple configuration screen like this 👇 choose “install the package maintainer’s version” (This ensures a clean, default setup for PostgreSQL 18.)

Step 7 — Verify Installation

Check the installed version you should see:

psql --version
psql (PostgreSQL) 18.x

That’s it! You’ve successfully installed and verified PostgreSQL 18 on Ubuntu 24.04 (Noble).

Your system is now running the latest, officially supported PostgreSQL version, ready for use in production or local development.If you encounter any issues, check the PostgreSQL service logs with:

sudo journalctl -u postgresql

Otherwise — you’re all set to start building with PostgreSQL 18.