# Logical security over Current User actions **URL:** \ **Category:** Development\ **Created:** [November 23, 2020, 10:15pm UTC](https://meta.discourse.org/t/logical-security-over-current-user-actions/171089 "2020-11-23T22:15:22Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![feabila](https://avatars.discourse-cdn.com/v4/letter/f/e9bcb4/32.png) [@feabila](https://meta.discourse.org/u/feabila)\ **Post date:** [November 23, 2020, 10:15pm UTC](https://meta.discourse.org/t/logical-security-over-current-user-actions/171089/1 "2020-11-23T22:15:22Z")
Yoo! How are you !? I have been doing some work around logical security based on current user information, like ´if this topic.creator.username to be equals to User.current().username´ I allow the user to edit topic or exclude! So, the point is, I need to guarantee some actions based on User session! But I have been doing some tests, and that’s why I’m here now asking you. Through Javascript in web browser (even in production mode), I’m capable of Discourse.User.current().set(‘username’, ‘sometestename’). This way, some actions in my system would be enabled just by this change. I know It’s not the goal of 99% of the users, but above this case, do you know guys some way to make sure user will not manipulate user information ? Best Regards, Felipe ---
**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\ **Post date:** [November 23, 2020, 10:19pm UTC](https://meta.discourse.org/t/logical-security-over-current-user-actions/171089/2 "2020-11-23T22:19:49Z")
> [@feabila](#): > > This way, some actions in my system would be enabled just by this change If you change information in your local browser, that does not change anything on the back end. The User is logged in via an authentication token, I believe, so you can’t masquerade as anyone else to the back-end: > [@(Deprecated) List of cookies used by Discourse](https://meta.discourse.org/t/list-of-cookies-used-by-discourse/83690): > > no_entry This topic is no longer being updated, and may not contain current information! To understand how Discourse uses cookies, please check the [cookies section of our privacy notice](https://www.discourse.org/privacy#heading--cookies). Name Essential Expires Description Contains personal data email Y Session Used during account creation, login, or password reset to prefill form. Created when E-mail address is provided in URL as a query parameter. Y destination\_url Y Session Used during login to redirect to the requested page. C… Because there is no fooling the server, you will not be able to make any change as another user. As soon as you refresh the browser, your local changes will probably be wiped out. Worst case you will probably mess up the javascript app state and have to delete your cache. ---
**Author:** ![feabila](https://avatars.discourse-cdn.com/v4/letter/f/e9bcb4/32.png) [@feabila](https://meta.discourse.org/u/feabila)\ **Post date:** [November 23, 2020, 10:37pm UTC](https://meta.discourse.org/t/logical-security-over-current-user-actions/171089/3 "2020-11-23T22:37:52Z")
Yoo! Yeah! As you said, the best way so would be always get current user session from back-end server. This way, cache changes from the browser couldn’t affect! Do you know somewhere I can check that logical security is based on user session from backend server, and not from PreloadStore ? Warn me if i’m pointing out wrong way! Thank you Robert for help! Best Regards, Felipe ---
**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\ **Post date:** [November 23, 2020, 10:41pm UTC](https://meta.discourse.org/t/logical-security-over-current-user-actions/171089/4 "2020-11-23T22:41:17Z")
I’m no security expert, just an app dev, but all persistent changes can only be made on the server. What happens on the browser in EmberJS is for the user’s convenience and superior usability experience, eg. caching for speed, automagic app-like interface behaviour. It doesn’t change the fact that ultimately it has to negotiate all persistent changes with the Rails server, and in doing so will only have permission to do so for the logged in user. Same goes for all data retrieval - the rails server is only going to send out data the logged in user is privy to. I don’t think you need to worry about this, because if anyone were to try to subvert this, they would fall at the first hurdle: there is no way to fool the API. What is your concern? ---
**Author:** ![feabila](https://avatars.discourse-cdn.com/v4/letter/f/e9bcb4/32.png) [@feabila](https://meta.discourse.org/u/feabila)\ **Post date:** [November 23, 2020, 10:48pm UTC](https://meta.discourse.org/t/logical-security-over-current-user-actions/171089/5 "2020-11-23T22:48:29Z")
I’m concerned because I’m working in some approaches which such action will be available or not depending on your User, if you are topic creator, if you are post creator, so this way I need to validate based on backend user session. Like this, on post the user can edit it, if you are the post creator. EDIT: Like the discourse post permissions, i will check it. ![Screen Shot 2020-11-23 at 19.47.42](https://global.discourse-cdn.com/meta/original/3X/d/d/dd73be853a9c28168ed23d9d33d423a3e11c4d2e.png) Best Regards, Felipe ---
**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\ **Post date:** [November 23, 2020, 10:50pm UTC](https://meta.discourse.org/t/logical-security-over-current-user-actions/171089/6 "2020-11-23T22:50:24Z")
You should develop all the security measures firstly on the back end. The rails serializers determine what data gets sent. The Guardian protects what actions are allowed. All of this is managed by the Rails Controllers. It doesn’t matter what junk the front end sends or what it requests to retrieve, because those elements protect the server. You can mirror this with front end behaviour, but the front end is not the gatekeeper. Check out a few of the larger plugins and you will see examples of Serializers and use of the Guardian. ---
**Author:** ![feabila](https://avatars.discourse-cdn.com/v4/letter/f/e9bcb4/32.png) [@feabila](https://meta.discourse.org/u/feabila)\ **Post date:** [November 23, 2020, 10:56pm UTC](https://meta.discourse.org/t/logical-security-over-current-user-actions/171089/7 "2020-11-23T22:56:58Z")
Thank you Robert, I needed this feedback! I will check it for sure! Best Regards, ---
**Author:** ![feabila](https://avatars.discourse-cdn.com/v4/letter/f/e9bcb4/32.png) [@feabila](https://meta.discourse.org/u/feabila)\ **Post date:** [November 25, 2020, 9:08pm UTC](https://meta.discourse.org/t/logical-security-over-current-user-actions/171089/8 "2020-11-25T21:08:30Z")
**Yoo Robert!** I have been analyzing plugin code and codebase about post controls (actions). To check which I could do the most about security. As analyzed! By front-end there are some steps which make sure if user can edit or not the post, like: - 1° step: SiteSetting.post\_menu\_hidden\_items - 2° step: attrs.canEdit - 3° step: editPost() - !post.can\_edit - controllers/topic But, even if manipulated by front, one time sent to the back end server in **posts\_controller.rb** , in ``` def update ``` It req again the post, by Rails, as a ultimate checks: - !guardian.public\_send(“can\_edit?”, post) - guardian.ensure\_can\_edit!(post) - PostRevisor Thank you for your insights! That’s so great. ---
**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\ **Post date:** [November 25, 2020, 11:28pm UTC](https://meta.discourse.org/t/logical-security-over-current-user-actions/171089/9 "2020-11-25T23:28:53Z")
Well done. Very pleased you kept going and dug further 👍🏻