CSRF Protection Part 2

Hey Milan V.!

You're just *barely* too early - the video is posted now :). And, I'm *thrilled* you found the course useful - I had such a great time writing it with Franks help! And yes, Redux is absolutely something we're thinking about... it's not a certainty yet... we're waiting to see more people ask for it. However, this tutorial has been very well-received, so I think there will be good demand to keep going with Redux.

Cheers!

Do it!!!!!

+1

+1 for Redux

+1 for Redux

+1 for Redux

Hey GDIBass!

Dude, you're 100% correct! This one still makes my head hurt... so I don't use it... yet. But, there have been many other ES6 things that I once did not like, and now love ;).

Glad you like the tutorial!

Cheers!

Hey AndTheGodsMadeLove

You are totally right! Looks like Ryan managed it like if it were an array, the right approach is using Object.assing({}, obj1, obj2); as you mentioned it.

Cheers!

Or... we can fix it like that:
headers = {...options.headers, ...headers};

Hey Alexander P.

Sorry for the late response. Somehow I missed this comment

Indeed you are right, that code works but it only works because we have installed babel-plugin-transform-object-rest-spread library

Cheers!

Hey Bruno D.

Thank you for your kind words, it means a lot. We have a course about React but it's not that advance as you may want, however, your feedback is very important to us and it help us to decide what course to develop next. Peace, cheers!

Just bought this course - thanks a lot guys for putting it together, a great way to support Symfony.

+1 from me for an advanced course as Bruno mentioned with routing, redux, local storage, session storage, needless to say, will buy it too! :-)

Hey xmontero!

Thanks for the kind note and spreading the word - that seriously means a lot ❤️

Said this, I feel something missing in the course. And if there's not a full chapter in it, probably at least "one pointer on how and where to investigate my myself" would be great:

Ah yes, real-time communication! I can give you a pointer on this :). As you suspect, what you basically want to do is "push" some updated state from the server to the client. Like you said, it's basically like you want to do polling to ask for the "latest state" for some component, but without the polling.

The way we typically do this in Symfony is with Mercure: it's a modern solution that serves the same purpose as Websockets. Basically, you can trigger an "Update" on the server to one or more topics. The "Update" can contain any data, but in your case, it would contain JSON for some new state. Then, in JavaScript, you subscribe to the topic. Then, anytime an "Update" is sent to that topic, a callback is executed in JavaScript.

Expecting a video making two replog lifter windows synchronize is expecting too much. But a "pointer" on where to start and how to update React components "from the server" would be truly appreciated!

So, for this, let's say that we decide to subscribe to a topic called user_rep_list_## where the ## is the current user's id. You can make topics "private" so that not anybody can listen to them, but I'll keep that outside of my explanation. Anyways, you listen to this in JS, and have a callback that will take the data from this "update" (e.g. a JSON list of the current rep logs) and set it onto the state of a component. Or, maybe you get fancier and send JSON with something like an "add" key in it, then you look for that and "add" that new rep log - e.g.:

{
    "operations": [
        {
            "action": "add",
            "data": {... the rep log}
        }
    ]
}

Hopefully you get the idea. Then, in PHP, on the Ajax endpoint that adds a new RepLog, you dispatch this Update to mercure with whatever data you want.

We do not have a tutorial specifically about Mercure, but we touch on it a few times - like https://symfonycasts.com/screencast/turbo/mercure (and the next few chapters). The big difference there is that we're sending HTML in the Updates and using some external JS to parse that HTML and use it. You would send JSON and then write your own code to subscribe to that topic and parse the JSON.

I hope this helps - it's far from a full description, but it's at least a pointer ;).

Cheers!

That is even better than a "pointer" ❤️

Pointer would be "mentioning mercure". Pointer squared would be your full text. Pointer cubed is what you did: giving even the links to specific videos.

Will definitively try it!

Thanks a ton.

Haha, yay! Well, I hope it works out - I've used Mercure now several times, but still never TOO heavily (though it is super fun). Let me know how it goes.

Cheers!

Thanks a lot, We are very happy when our tutorial gives good knowledge!

Cheers!

Hey John christensen!

Hmm. That *is* interesting. The class behind the cached annotations is this class - specifically this function - https://github.com/doctrine...

See that $this->debug flag? Symfony passes true to this in debug mode, and false in prod mode. When debug is true, that class actually checks to see if the class that the annotation lives on has been modified since the cache - https://github.com/doctrine...

That's a long way of saying... I have no idea what's going on in your case! When you modify the annotation, that modifies the file... which should cause that isCacheFresh() method to return false. If you're able to repeat this issue (and if you care enough), you could add some temporary debug code to that class to see what's going on. Symfony goes a long way to make sure that these cache problems don't happen... so something *is* indeed odd in your situation!

Let me know if you find anything out :).

Cheers!

Hey Skylar

Probably PhpStorm Symfony plugin is not smart enough to read those annotations as a Symfony Route. Try re-indexing your project after that change if it doesn't work you may have to tweak some config in order to make it to work

Cheers!

Hey Tobias I.@

This is definitely on our radar - especially as we get more into API's etc. What I *can* tell you is that, about the hardcoding, i wouldn't worry about it. We *do* hardcode routes increasingly, because we're thinking of our API as its own "standalone" thing and our frontend as its own "standalone" thing. URLs then become a sort of "contract", where your API "promises" not to change them and then your frontend can hardcode them (this is exactly how the world works when the API and user of an API are not the same "app"). This just forces you to "think" before changing any URLs (similar to how you would "think: before renaming any methods in your code): if you update a URL in your API, you just need to find and update it on the frontend. You *can* also use FOSJsRoutingBundle, if this really bothers you :).

Sorry I don't have anything more ready to tell you than that right now! But this is a general direction that we're moving, of course, with our tutorials.

Cheers!

Hey Bart

Which URL are you accessing? Remeber that it only works on RepLogsController routes. Oh, and can you double check that your ApiRoute extends from the right Symfony Route class?

Cheers!

Thanks for your reply Diego Aguiar :) I'm positive I'm extending the correct class, it's just that when I use the @ApiRoute() annotation it doesn't work above a single method, it only works above the entire class. Ryan points out in the video it should work with just a single method?

Hmm, it only works when you use it on the entire class? That's odd. I may have to see your code, if you can upload it to Github or somewhere else

The code is visible at https://bitbucket.org/bschutte/apiroute/src/master/ Hopefully this allows you to spot the problem :) Alternatively you could check out the repo and have a look at http://127.0.0.1:8000/ which is a test page on which you can reproduce the problem

Wow, you are right, this is not working on methods. This might be a Symfony's bug. I'll ask Ryan about this
Thanks for sharing your case :)

Hey MolloKhan!

Ah, this was a tricky one! But.. it IS working ;). It comes down to one small detail. You currently have:

    /**
     * @ApiRoute()
     * @Route("/stories/{slug}", name="stories_slug_set", methods={"POST"})
     */
    public function setStory()

The result is that this created TWO routes - you can see them if you run php bin/console debug:router:

-------------------- -------- -------- ------ -------------------------- 
  Name                 Method   Scheme   Host   Path                      
 -------------------- -------- -------- ------ -------------------------- 
  app_story_setstory   ANY      ANY      ANY    /                         
  stories_slug_set     GET      ANY      ANY    /stories/{slug}           

The FIRST one comes from the ApiRoute, and it DOES have the _is_api default. The second is just a normal route. Basically, you should use ApiRoute instead of Route, not along with it. Both Route and ApiRoute create routes. In your case, you've created two routes - one that is an "api route" and one that is a normal route. Try this instead:

    /**
     * @ApiRoute("/stories/{slug}", name="stories_slug_set", methods={"POST"})
     */
    public function setStory()

Let me know if that works!

Cheers!

Hey Askan S.!

Great question :). Your first option is ... don't use API keys! Just use session-based storage and cookies like we do in this tutorial. It's simple & secure (as long as you have your user use HTTPS, which you always should). But yes, I see you are already using API keys ;).

The issue with API tokens is where to store them? And, honestly, there's a lot of conflicting info about this. For example: https://dev.to/rdegges/plea... - according to this resource, using local storage is not an option (though it would be really simple!). Other places - https://auth0.com/docs/secu... (which is a great site I trust) - absolutely show local storage being used - they even show it in their quick starter docs: https://auth0.com/docs/quic...

So... there is clearly some security issues with using local storage... though *how* big of a deal, is debated :/. You're right that putting the API key as a global JavaScript variable is not a good idea. Well, it's actually the same as "local storage" - other JavaScript running on your page could access it.

So, use local storage... or if you really care about security, use sessions & cookies :). That's probably not the exact answer you wanted, but that's the state of things :).

Cheers!

Dear weaverryan, thank you very much for your detailed answer.
I thought lot about it and came to similar conclusions,
and have rebuilt the app sessionbased like in your tutorial.
But there is a disadvantage. How can I share the Api with
other programs, that do not use the frontend? I think
a new Route ("apiextern") and in additional authorisation
etc. is the solution ;) Best Regards Askan

Hey Askan S.!

Ah! So if you want external programs to use your API, that's different. That IS a more appropriate use-case for having API tokens. What I'd recommend is *two* authenticators: one for the normal, session-based authentication and another that allows token-based authentication. Then, you can use the session-based login for your JavaScript app and allow the external applications to send an API token.

If you have some more questions about this, I'd be happy to answer :).

Cheers!