Leaderboard

I'd probably just do that if it were me. Regenerating the user on every request isn't really going to be an issue I think, and might be necessary anyway more often than you'd think. I think what this error means is that you're trying to persist the App\Security\TokenUser object, but that object does not correspond to any known entity. Likewise for the other class. I've never used this library so really don't know anything about it. My initial comment was based on a quick look at the class where it seemed like it just extracted a string value from a user object. Doing a little more googling, I'm thinking maybe doctrine's reference proxies might be a solution for you. Since I don't know how things are structured, I can't really provide a good example but whever you were passing a fully hydrated user before, you'd change to just passing a reference, something like: $reference=$em->getReference(User::class, $jwt->getUserIdentifier()); $blamable->setUser($reference);

that doesn't matter. the main point of using prepared queries is to prevent any sql special characters in a value from breaking the sql query syntax (which is how sql injection is accomplished.) currently, a value that contains a ' (singe-quote) will break the sql query syntax and produce an error, rather than to allow the UPDATE query to execute. what if the user on your site has a name that contains a ' or wants to use one in their username? using a prepared query also simplifies the sql query syntax, making it easier to write a query that doesn't contain typos. a header() statement doesn't stop php code execution. you must use an exit/die statement with/after a header() redirect to stop php code execution. currently (before the last posted code), all the rest of the code on the page executes every time it gets requested, even if the user isn't logged in. it's not about using them only one time (you can use them any number of times.) this is about writing code that doesn't contain a lot of unnecessary clutter that you want someone else to look at and help you with. when you post code that contains as much as 2x the amount of typing in it that is necessity, it makes it harder for the people who would help you. it also takes your time typing and fixing mistakes in all the unnecessary typing. the points that were made about the php code are coding practices that will help make the code secure, simplify it, help reduce mistakes, ... here are some more points about just the posted php code - error_reporting should always be set to E_ALL and the setting should be in the php.ini on your system, so that you can change it in a single place. don't use output buffering to make bad code work. find and fix whatever is preventing your code from working. using output buffering also makes debugging harder because it hides non-fatal php errors and any debugging echo output you use, when you execute a header() redirect. the only value you should store in a session when the user logs in is the user_id. query on each page request to get any other user information (which you are doing) such as the username, permissions, ... this insures that any changes made to the other user information will take effect on the next page request. don't copy variables to other variables for nothing. this is a waste of typing time. just use the original variables. don't unconditionally destroy the session. the session can hold things other then the logged in user_id. the session user_id will either be set or it won't. you don't need to create a bunch of variables and logic to detect if there is a logged in user or not. your should build the sql query statements in a php variable. this makes testing easier and help prevent typo mistakes by separate the sql query syntax as much as possible from the php code. don't use variables ending in numbers. this just makes more work for you keeping track of what you are doing in your code. you should list the columns you are selecting in queries. this help make your code self-documenting and helps prevent mistakes. outside of the log in code, you should NOT select and fetch passwords. don't use a loop to fetch data from a query that will match at most one row of data. just fetch the data. don't store passwords in plain text. use php's password_hash() and password_verify(). don't attempt to detect if a form submit button is set. there are cases where it won't be. instead detect if a post method form was submitted. one case where the submit button won't be set is if you upload a file that exceeds the post_max_size setting. in this case, both the $_POST and $_FILES arrays will be empty. your post method form processing code must detect this and setup a message for the user that the size of the post data was too large and could not be processed. after you have detected that there is $_FILES data, you must test the ['error'] element and only use the uploaded file information if there was not an upload error (the errors are listed in the php documentation.) your post method form processing code should trim then validate all $_POST inputs before using them. apply htmlentities() to any dynamic value when you output it on a web page to help prevent cross site scripting. finally, these points just apply to the php code. your makeup is not working due to the mistakes in the html document. you need to clean up the html document so that it only loads each external element once and is valid markup.