I'm using Symfony2 version 2.0.5 with the bundled Doctrine ORM solution. Since I changed the environment from dev to prod, all my form inputs are escaped, when persisting to database. Now I know this is the correct behaviour for preventing sql injections, but when fetching the data back, the string isn't unescaped. Because I directly save JSON strings to database this is causing me big problems.
Also everytime I update this data the string gets escaped again and again.
My Question is, can I deactivate the escaping for certain fields, should I? Or can I unescape the values when fetched from the DB.
And why is this only happening in prod environment? Is this intended?
Best Regards, David!
This is probably caused by PHP configuration — not by Symfony or Doctrine. In php.ini, find all options starting with magic_quotes_ and set them to Off. Don't forget to restart the server.
Related
I use Symfony 6.1 , Doctrine, Fixtures, phpunit and Zenstruck Foundry Bundle.
The session is kept in the database.
In a WebTestCase I want to reset the test database and use the ResetDatabase trait for this.
But that doesn't work because the session table isn't deleted with doctrine:schema:drop
As soon as doctrine:schema:create is executed, there is an exception because the session table already exists.
I found out that the session table is on the blacklist and must not be deleted. It also doesn't work with "--full-database".
How do I have to configure the Foundry Bundle or Doctrine to make it work?
Please excuse my bad English
I found this, but unfortunately it doesn't offer a solution.
https://github.com/doctrine/orm/issues/8976
I guess I found the mistake.
Someone created a session entity. :(
This seems to affect the behavior of doctrine:schema:create.
I've been testing stuff out with Superset and I think I corrupted my superset db. When I try to acess any chart i get this error:
I found a workaround to this problem, by searching with ag - the silver searcher which individual migration dropped the dbs.perm table, and using the command
superset db downgrade <migration-id>
on the migration prior to that one.
It's still not very clear to me which steps I would take as to completely reset the db safely.
I have the manual, dev installation since I'm working on customizing the code. Let's say I didn't have anything too important in the db, so I'm not afraid to loose tables, users, perms, etc.
I've found I have a superset.db in ~/.superset, but I don't think deleting that will be enough, right?
How can I reset Superset's db so as to make a clean db and start over? Can I do this without losing my Superset installation, or do I need to start over completely? In any case, can you guide me through it?
You need not to reinstall everything. Just remove the ~/.superset/superset.db file and take the backup of this file before removing it just in case you want to restore it. and then run the below commands. These commands will create another database file.
Initialize the database
superset db upgrade
Create an admin user (you will be prompted to set a username, and first and last name before setting a password)
$ export FLASK_APP=superset
$ superset fab create-admin
Load some data to play with
superset load_examples
Create default roles and permissions
superset init
deleting superset.db in ~/.superset should be enough and it's the more clean way to start over. Yet note that SQLLite is not a recommended DB engine for metadata and it's support should be completely removed on the future.
I also recommend using the docker-compose provided for testing/developing on Apache Superset
I have some beginners questions regarding Symfony 2 which I cannot get clear answers for from previous questions (perhaps because they are genuinely basic)
When you create a new symfony2 project from the command line and specific the database name and passwords, is this meant to automatically create the database (which you can see in phpmyadmin) or does one manually do this.
Following from this, if one creates a number of entities and then uses
doctrine:schema:update
Should the specified tables be automatically created in the database you have specified in the projects "parameters.yml" file.
I have performed "doctrine:schema:update --force" which then gave me
Updating database schema...
Database schema updated successfully! "2" queries were executed
But no tables were created. So I tried again, to see what the message would be...
unknown-ec:35:86:4d:41:5e:symfony simonalice$ php app/console doctrine:schema:update --force
Nothing to update - your database is already in sync with the current entity metadata.
unknown-ec:35:86:4d:41:5e:symfony simonalice$
So clearly Doctrine thinks its in synch - but no tables in phpmyadmin.
Clearly complete beginners stuff....but I would be grateful for some steerage on this from a Symfony 2 veteran.
To answer your questions:
No, creating a new Symfony project will not create your database (or the user connecting to it). You still need to do that and I would recommend you create a dedicated user for your application with suitable permissions. You'll need to use a database user with administrative privileges to do this. For security reasons, it's best to not use your database administrator account with your application. To instruct doctrine to create your database (once you have your db user and connection parameters set), you can run the php app/console doctrine:database:create console command.
Yes, running the doctrine:schema:update console command will generate your database entities, but it won't/can't create your database. You can also use the --force option to apply changes you've made since the last update. These updates will still be bound by any column constraints you've defined, so if for example you change an existing nullable column to not null, you'll get an error if records already exist with null values.
Hope that helps.
I have a wordpress installation on sql server 2008 r2. I am not a php man myself, so I'm not really sure how to attack the php side.
On the sql server side I can see question marks being stored, so this is not just a presentation issue.
I am thinking maybe the insert itself does not have an N before the string.
Can anyone point me to where I can start looking in the php files, or even better is there is a known solution for this issue?
Edit: I already checked and all fields are nvarchar.
Edit 2: I just manually inserted the data into the DB and it is stored correctly.
Check your wp-includes/wp-db.php file.
Wpdb is the core database object used for db operations.
I have set up a little server on an old XP Pro box, with php 5.3.1.
In order to use it as a test box to mirror our hosted site, I need to get sqlite sessions working.
While sqlite is definitely there in phpinfo(), I can't seem to get php.ini to use it as a save handler:
Registered save handlers - files user
In php.ini, I've got
session.save_handler = sqlite
session.save_path = "D:\temp\php-session"
A good question to have answered first is, does the SQLite plugin you're using expose itself as sqlite or sqlite3?
You may try using sqlite3 as your session.save_handler value. Make sure you start your sessions, too!
if you want to use SQLite as a session handler, two options :
It's registered as a session handler (you can check this in the phpinfo() > Registered save handlers). Usually it's "User, files" which means that you can't use SQLite as a session handler directly.
You can write your own session handler by implementing session_ set_save _handler(). An example is given in the manual.
The problem turned out to be the system variable PHPRC not being read for some reason. My php.ini was being ignored.
Found this out by going thru and redoing EVERYTHING over again to make sure I hadn't misconfigured something somewhere. I didn't see any difference between the old and new var, but after a reboot things were suddenly coming up roses.
Thanks to everyone who offered suggestions!