I’m working with a CRM platform that uses Symfony on the backend and AngularJS for the frontend. The current version relies heavily on GraphQL for API communication.
I need to authenticate programmatically using the same API calls that the frontend uses. When I examine the browser’s network activity, I can see two main endpoints:
When I try to replicate this in Postman, I get a 401 error saying “Invalid CSRF token.” This suggests I need some kind of token even for the initial login request.
Looking at the browser’s request headers, I see multiple cookies including:
How do I get this CSRF token initially? The frontend somehow obtains it before making the login request. I’ve tried different approaches in Postman, Python, and n8n but can’t figure out the proper authentication flow.
Is there a preliminary request I need to make to get the CSRF token? How does the browser get it on the first page load?
Check the response headers from your initial GET request to the main domain. Symfony often sends CSRF tokens through Set-Cookie headers alongside the HTML content. I’ve worked with several Symfony/GraphQL setups - sometimes the token isn’t in the page markup at all. It comes as a separate cookie that browsers handle automatically. Make a GET request to the root domain first and check all response headers. Look for CSRF-TOKEN, XSRF-TOKEN, or similar in the cookies. Some apps also have a dedicated endpoint like /api/token or /security/csrf-token that returns JSON with the current token. Once you have the token, send it back in requests either as a header (X-CSRF-TOKEN) or in your request cookies. The exact setup varies between Symfony versions and how developers configured their security.
been there with symfony crm. the fix is cookies - symfony auto-sets the csrf token as a cookie on your first visit. in postman, turn on cookie handling or just copy all cookies from your browser session. your auth request will work after that.
Yeah, CSRF tokens are a pain with Symfony apps. The browser definitely grabs it before making the auth request.
Here’s how you can get that initial token:
GET the main app page and scrape the HTML for something like <meta name="csrf-token" content="xyz789">
Look for a /csrf or /token endpoint that just returns the token.
Sometimes it’s buried in a script block on the page.
But manually handling CSRF tokens across different tools sucks. You’re stuck chaining requests, parsing responses, dealing with token refresh, and keeping session state straight.
I’ve done similar integrations with complex web apps. Rather than fighting with Postman scripts or writing custom Python, I used Latenode for the whole flow.
You can scrape the initial page for the CSRF token, chain it to your auth request, then hit your GraphQL calls. Latenode handles session management and passes tokens between requests automatically.
When the token expires or the API changes, you just update the workflow instead of fixing code everywhere.
You’re receiving a “401 Invalid CSRF token” error when attempting to programmatically authenticate with a Symfony/AngularJS/GraphQL CRM platform. This indicates that your authentication request is missing a required Cross-Site Request Forgery (CSRF) token. The browser obtains this token implicitly, but you need to explicitly retrieve it for your programmatic request.
TL;DR: The Quick Fix:
Try making a preliminary GET request to the main application URL (domain.com) before your authentication POST request. The CSRF token is likely sent as a cookie in the response. Your authentication POST request then needs to include this cookie.
Understanding the “Why” (The Root Cause):
Symfony often uses CSRF tokens to prevent malicious requests. These tokens are unique identifiers that must be included in POST requests to ensure they originate from a legitimate source (your browser in this case). The browser implicitly handles this token exchange during the initial page load. When a user initially visits the site, the browser makes a GET request to the main URL (domain.com). The server responds with HTML and includes a CSRF token in a cookie. Subsequently, subsequent requests, such as the POST to /auth, will include this cookie containing the CSRF token. Since your programmatic authentication is skipping this initial GET request, you’re missing the crucial CSRF token.
Step-by-Step Guide:
Make a Preliminary GET Request: Use your chosen tool (Postman, Python, n8n) to make a GET request to the root URL of your CRM, domain.com. Crucially, ensure your tool is configured to handle cookies. The server response should include an HTML page, but importantly, it will also set a cookie containing the CSRF token (e.g., CSRF-TOKEN).
Extract the CSRF Token: After making the GET request, your tool should have stored the received cookies. Retrieve the CSRF-TOKEN cookie value from the response. How you do this depends on the tool you are using.
Postman: Check the “Cookies” tab in Postman after the GET request. You should see a cookie named CSRF-TOKEN with its associated value.
Python: Use libraries like requests to manage cookies. The response object from your GET request will contain a dictionary of the cookies received. You can access the CSRF token using its name.
n8n: Use a Set node to extract the cookie from the response body. You may need to use Javascript function nodes or expression nodes to parse the cookies and extract the CSRF token depending on the response format and version of n8n being used.
Include the CSRF Token in Your Authentication Request: Make your POST request to domain.com/auth. Include the CSRF-TOKEN either in the request headers (e.g., as X-CSRF-TOKEN or a similar header, depending on the CRM’s configuration), or within the request cookies. Again, the exact method depends on your specific tool and the CRM’s requirements.
Common Pitfalls & What to Check Next:
Cookie Handling: Double-check that your chosen API client (Postman, Python, n8n) is properly configured to handle cookies. In some clients, cookie management must be explicitly enabled.
CSRF Token Name: The actual name of the CSRF token cookie might differ (e.g., XSRF-TOKEN, _csrf_token). Inspect the cookies in the response of your GET request to identify the correct name.
Header vs. Cookie: If including the token in the header, be sure that the server expects the token to be in the specific header you’re using. If you’re including the cookie, be sure that the cookie is sent in the request headers correctly.
Alternative CSRF Token Location: While the CSRF token is usually sent as a cookie, some applications might include it within the HTML response itself (e.g., in a meta tag or hidden form field). If you can’t find it as a cookie, examine the HTML response for alternative locations.
Dedicated Token Endpoint: Some Symfony applications have a dedicated endpoint for retrieving the CSRF token (e.g., /api/token or similar). Check the application’s documentation for this possibility.
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!
Had this same problem with a Symfony app recently. You can’t just grab the CSRF token - you need to understand the whole request flow. The network tab only shows you part of what’s happening. Before that auth request, the browser makes an initial GET to set up the session context when the page loads (usually /login or the main app URL). That response gives you the session cookie AND CSRF token, typically in a form field or meta tag. Your API client has to do the same thing. First, GET the login form page. Pull out both the session cookie and CSRF token. Then POST to /auth with both pieces. Session cookie goes in the Cookie header, CSRF token usually goes in X-CSRF-TOKEN header or as a form field. Missing either one and Symfony’s security will reject you even with correct credentials.
Most Symfony apps embed the CSRF token right in the initial page response. When you visit the app in a browser, it makes a GET request to the main route and gets back HTML with the token inside. You’ll need to copy this with your API client. First, make a GET request to the main app URL (usually just the domain root). Then parse the HTML response - look for a meta tag with the CSRF token or check if it’s stuck in JavaScript variables. I’ve seen apps put it in window.csrfToken or similar globals. Once you’ve got the token, include it in your auth request headers as X-CSRF-TOKEN or whatever header the app expects. After you authenticate successfully, keep those session cookies for your GraphQL requests. This two-step process is pretty standard for Symfony apps with CSRF protection turned on. Just mimic what the browser does - GET the page first, grab the token, then authenticate.
Manual cookie handling works but gets messy fast with token expiration and session management across multiple API calls.
I’ve automated this exact flow for several CRM integrations. The trick is building a workflow that handles the entire auth chain without manual work.
First step grabs cookies and embedded tokens from the main domain. Then it extracts the CSRF token from HTML meta tags or response headers. Next, it fires the auth request with proper headers and keeps session state.
Once you’re authenticated, all GraphQL calls flow through with the right cookies. When tokens expire, the workflow reruns the auth sequence.
This beats copying cookies from browser dev tools or writing Python scripts to parse HTML. You get reliable auth that works even when backend teams change token formats or endpoints.
Latenode handles cookie management and request chaining automatically. Much cleaner than juggling session state across different tools.
Understanding the “Why” (The Root Cause):
Step-by-Step Guide:
Common Pitfalls & What to Check Next:
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!