This token is created and maintained by Phoenix through requests, and in:

pipeline :browser do
    plug :accepts, ["html"]
    plug :fetch_session
    plug :fetch_flash
    plug :protect_from_forgery
    plug :put_secure_browser_headers
    plug CORSPlug
  end

The protect_from_forgery plug line is what checks that they match. It’s not the same as your JWT token.

In your case I assume you want to keep the CSRF protection (you have regular pages and not an API only backend) but at the same time you want to test it from an external program that just emits requests. In this case you can temporarily comment out the plug line in the router pipeline (which is fine if you remember to put it back and just want to try some quick test).

If you want to use this in tests more systematically then you can also [disable csrf for testing] purposes (Plug.CSRFProtection — Plug v1.20.2)

@amnu3387 I was in smilar situation as topic owner. I get a post request from a third party api. I created new pipeline without protect_from_forgery . Is that security issue?. Example of my controller.

	request =[
    processId: get_session(conn, :current_process_id),
        token: get_session(conn, :token)
    ]

    json_respond = MyApp.ThirdPartyApiCient.check_process(request)
    {:ok, respond } = JSON.decode(json_respond)

    if respond["status"] == "SUCCESS" do
    ...

It’s very easy to see if it can be a security issue, just ask, “if I knew the route to where to direct a post request, along with a certain payload” would I be able to trigger it’s side effects? Then depending on the side-effects it will be or not a security issue.
If to make the request produce its side effects I require information that is temporary and changing in nature and not available to me (a JWT token, a session token, a payload signature) then it’s safe (up to a reasonable expectation) I would say

That is a callback path. I get process token from session. And after success status app deletes session. I dont take any paramater from params. Also can i handle that callback with default browser pipeline ?

Edit: i added "#{Plug.CSRFProtection.get_csrf_token]" end of callback now i use default browser pipeline. Thanks @amnu3387

Thanks so much ..

I’ve put

key = x-csrf-token
value = KQE+CSIJIhoMRXIeFVc1fxYqPCBxJgAAEBFPWBLie35hXaGLWiVK4Q==

in the Headers section of Postman, but still get the CSRF error … must be still doing something wrong.

[{“key”:“x-csrf-token”,“value”:“KQE+CSIJIhoMRXIeFVc1fxYqPCBxJgAAEBFPWBLie35hXaGLWiVK4Q==”,“description”:“”,“enabled”:true}]

how about when you pass as ‘_csrf_token’ param ?

Edit: I got same error when i created in command line. But when app creates in controller it works

Actually that wouldn’t work at all since there won’t be a session nor token for it to be matched. What I wrote earlier doesn’t make sense (printing the token in the console), since it will retrieve you another process csrf token (for the console process), which won’t match the process handling the incoming postman request.

Not having used Postman in this situation, I would imagine that you need to request the login, read the answer back and use that to further query your endpoint. You could pass the csrf token in the login response as well and then use that to set the header, along with your JWT, or encode it inside the JWT as well and forego the CSRF protection plug. (I never used JWT either but I think it’s how it’s done when you’re using JWT…). But sincerely, probably it’s just easier to disable the plug for testing…

@amnu3387 i added <%= Plug.CSRFProtection.get_csrf_token %> to my index page. I visited index page using postman. I tested nearly 20 tokens manually using postman again. But some of them working some of them not working. A bug ?

I have no idea

I digged more when a token includes + it doesnt work. for example

"HVIlKXk5eEYJby8uQW8dCTc+ISkINgAAy9Ka2p45OWci27Y9uOIYDA=="

at error screen that token turns to that, plus dissappears
"HVIlKXk5eEYJby8uQW8dCTc ISkINgAAy9Ka2p45OWci27Y9uOIYDA=="