DEV Community

Jeffrey.Feillp
Jeffrey.Feillp

Posted on

Reverse-Engineering Dev.to's CSRF Authentication for Automated Publishing

Reverse-Engineering Dev.to's CSRF Authentication

I recently needed to automate publishing articles to Dev.to. The official API works, but requires generating an API key from settings. I wanted a simpler approach — and learned some interesting things about Dev.to's authentication along the way.

The Challenge

Dev.to uses Rails' built-in CSRF protection. Every form submission requires an authenticity_token. Getting this token and keeping sessions alive was the main challenge.

What I Discovered

1. Login Flow

Dev.to's login endpoint is at /users/sign_in. The CSRF token is embedded in the login page at /enter:

import requests, re

session = requests.Session()
login_page = session.get('https://dev.to/enter')
csrf = re.search(
    r'authenticity_token.*?value="([^"]+)"', 
    login_page.text
).group(1)
Enter fullscreen mode Exit fullscreen mode

2. Session Persistence

After login, Dev.to sets a session cookie and a remember token. These can be saved and reused:

# Save session
session_data = {
    'cookies': dict(session.cookies)
}
json.dump(session_data, open('session.json', 'w'))

# Restore session
session.cookies.update(json.load(open('session.json')))
Enter fullscreen mode Exit fullscreen mode

Sessions last for weeks with remember_me enabled.

3. Article Creation CSRF

The interesting finding: the CSRF token from the dashboard page works for article creation. You don't need to fetch the /new page's token. The dashboard token is valid for form submissions across the site.

dashboard = session.get('https://dev.to/dashboard')
csrf = re.search(
    r'authenticity_token.*?value="([^"]+)"', 
    dashboard.text
).group(1)

# Same token works for publishing
session.post('https://dev.to/articles', data={
    'authenticity_token': csrf,
    'article[title]': 'My Title',
    'article[body_markdown]': '# Content',
    'article[tags]': 'python,devto',
    'article[published]': '1',
})
Enter fullscreen mode Exit fullscreen mode

4. Rate Limiting

Dev.to enforces rate limiting at roughly 1 article per 30 seconds. Exceeding this returns a 422 error. Adding a 35-second delay between publishes handles this reliably.

The Complete Solution

I turned this research into a working batch-publishing tool. It handles:

  • Session login with automatic re-authentication
  • CSRF token management
  • Rate limit awareness
  • Batch processing with status logging
  • YAML frontmatter parsing

Get It

The complete tool is available as a one-time purchase:

$15 USDT (TRC-20) — no subscription, no cloud dependency.

TNeUMpbwWFcv6v7tYHmkFkE7gC5eWzqbrs
Enter fullscreen mode Exit fullscreen mode

Full details: https://telegra.ph/Devto-Batch-Publisher--15-USDT-One-Time-Purchase-04-29

Includes: 3 scripts, README (EN + CN), requirements.txt, example article, cron setup guide.


Questions about the technical details? Drop a comment below.

Top comments (0)