UPDATE: problem solved, see the comments (many issues, the versions differences was but one of them).
I'm trying to configure sessions in Symfony2 in config.yml file. I have the following configuration:
session:
default_locale: %locale%
lifetime: 7200
auto_start: true
storage_id: session.storage.pdo
parameters:
pdo.db_options:
db_table: session
db_id_col: session_id
db_data_col: session_value
db_time_col: session_time
services:
pdo:
class: PDO
arguments:
- "mysql:dbname=%database_name%"
- %database_user%
- %database_password%
session.storage.pdo:
class: Symfony\Component\HttpFoundation\SessionStorage\PdoSessionStorage
arguments: [#pdo, %session.storage.options%, %pdo.db_options%]
It's based on Symfony2's cookbook http://symfony.com/doc/2.0/cookbook/configuration/pdo_session_storage.html
I've created exactly the same table as in the given link.
However, it doesn't work. I get some "blank" error (no error message, but "PDO Exception" and "Error Exception"). I admit I have no much knowledge on configuring the Symfony2 or any info (that's why I'm using cookbook). I lost a lot of time and see no much documentation about it in the internet, not mentioning the fact that internet is quite silent about this case (having session storaged to DB table in Symfony2).
My NetBeans is "shouting" sth about the last line:
arguments: [#pdo, %session.storage.options%, %pdo.db_options%]
"ScannerException while scanning for the next token we had this found character #(64) that cannot start any token".
UPDATE:
Hmm now I'm not sure if it's about the configuration. I can see that Symfony2's cookbook (use... ) example doesn't match actually the file structure in the Symfony2's bundle. In a word, there is no such file-path, but after putting the real one it still doesn't work.
I had the same problem as you with Symfony 2.5. Turns out my solution was to disable session.auto_start in php.ini. The PdoSessionStorage will not take over if the session is being started before PDO has the opportunity to take control of it. I had overlooked this at first because I was modifying the wrong one (I had two copies of php.ini). To check if this is the problem on yours, run this command:
echo ini_get('session.auto_start');
If that returns a '1' or a 'true', then be sure to set this in your php.ini:
session.auto_start = 0
So for reference, here is my setup with Symfony 2.5 to make this work:
config.yml
framework:
session:
handler_id: session.handler.pdo
parameters:
pdo.db_options:
db_table: session
db_id_col: session_id
db_data_col: session_value
db_time_col: session_time
services:
session.handler.pdo:
class: Symfony\Component\HttpFoundation\Session\Storage\Handler\PdoSessionHandler
arguments: ["#pdo", "%pdo.db_options%"]
pdo:
class: PDO
arguments:
dsn: "mysql:host=%database_host%;port=%database_port%;dbname=%database_name%"
user: "%database_user%"
password: "%database_password%"
calls:
- [setAttribute, [3, 2]] # \PDO::ATTR_ERRMODE, \PDO::ERRMODE_EXCEPTION
Related
I'm not very successfully trying to figure out how to achieve an override of a group/package with and via a yaml file. Trying to explain my problem using the example (files and folder structre) from the hydra documentation https://hydra.cc/docs/tutorials/structured_config/schema/.
yaml.config as:
defaults:
- base_config # --> reference to dataclass
- db: base_mysql # --> reference to dataclass
- _self_ debug: true
gives the expected (print when running the myapp.py):
db:
driver: mysql
host: localhost
port: 3306
user: ???
password: ???
Using the yaml file instead instead of the base_mysql dataclass is also fine thus the yaml.config as:
defaults:
- base_config
- db: mysql # --> reads db/mysql.yaml
- _self_
debug: true
prints again as expected
db:
driver: mysql
host: localhost
port: 3306
user: omry
password: secret
Overriding individual fields is as well fine, e.g. with config.yaml like
defaults:
- base_config
- db: mysql
- _self_
debug: true
db:
password: UpdatedPassword
What I'm to able to figure out is how to override the full db group with a/via another yaml file - defining the structure via a dataclass and then override/set the values like:
defaults:
- base_config
- db: base_mysql # --> reference to dataclass to define the structure
- _self_
debug: true
db: mysql # --> mysql.yaml
throws the following error:
In 'config': Validation error while composing config:
Merge error: str is not a subclass of MySQLConfig. value: mysql
full_key:
object_type=Config
Searching the internet/stackoverflow already showed me that moving the self to the first position will get rid of the error - but then the composition order is "wrong".
Keeping the order as it is and using the mysql.yaml for an override works well - when done via commandline (python myapp.py db=mysql when the line "db:mysql" is not present), but for my usecase it much more convinient to handle it all via the yaml file(s).
Somehow I assume that the same functionality is available via CLI and files/code and that I just did not mange to figure out how it works.
(hydra version 1.1 in a conda environment with python 3.9)
Thank you very much in advance for any help that you can provide.
If understand correctly, you want to use the defaults list in your primary yaml file to merge together the base_mysql config with the mysql config. This will do the trick:
defaults:
- base_config
- db: [base_mysql, mysql]
- _self_
debug: true
Passing a list [base_mysql, mysql] of config names causes those configs base_mysql and mysql to be merged together. This is documented here -- see the "CONFIG_NAMES" alternative for specifying an option in the defaults list.
Note that passing the CLI override db=mysql (as in python myapp.py db=mysql) results in modification of the defaults list; the resulting defaults list will be the same as if you had used the following in your yaml file:
defaults:
- base_config
- db: mysql
- _self_
debug: true
You can pass a list [base_mysql, mysql] of config names at the CLI like this:
python my_app.py 'db=[base_mysql, mysql]'
Existing questions did not help.
I am still learning Symfony and setting up an existing project. Trying to run doctrine fixtures from my application directory.
./app/console doctrine:fixtures:load --env test
And running this gives me following errors
Error thrown while running command "doctrine:fixtures:load --env test --em default". Message: "The class 'ClientPortal\GenericBundle\Document\Accountant' was not found in the chain configured namespaces _XyzProjectName\CalendarContext\Domain\Model, Integration\GetFeedbackBundle\Model, _XyzProjectName\AccountingProcessContext\Domain\Model, _XyzProjectName\CaseContext\Domain" {"exception":"[object] (Doctrine\Common\Persistence\Mapping\MappingException(code: 0): The class 'ClientPortal\GenericBundle\Document\Accountant' was not found in the chain configured namespaces _XyzProjectName\CalendarContext\Domain\Model, Integration\GetFeedbackBundle\Model, _XyzProjectName\AccountingProcessContext\Domain\Model, _XyzProjectName\CaseContext\Domain at /usr/local/var/www/1800-api/vendor/doctrine/persistence/lib/Doctrine/Common/Persistence/Mapping/MappingException.php:22)
And this exception is being thrown when trying to persist object of class
'ClientPortal\GenericBundle\Document\Accountant'
and here is my doctrine in config.yml
doctrine:
dbal:
driver: pdo_pgsql
host: '%database_host%'
dbname: '%database_name%'
user: '%database_user%'
password: '%database_password%'
orm:
auto_generate_proxy_classes: "%kernel.debug%"
auto_mapping: true
mappings:
CalendarBundle:
prefix: '_XyzProjectName\CalendarContext\Domain\Model'
IntegrationGetFeedbackBundle:
prefix: 'Integration\GetFeedbackBundle\Model'
AccountingProcessBundle:
prefix: '_XyzProjectName\AccountingProcessContext\Domain\Model'
CaseBundle:
prefix: '_XyzProjectName\CaseContext\Domain'
GenericBundle:
type: "annotation"
prefix: 'ClientPortal\GenericBundle\Document'
dir: 'src'
is_bundle: false
The snippet which is raising this exception
$account = new ClientPortal\GenericBundle\Document\Accountant();//full namespace added for clarity - also this file lies in the same directory structure.
$account->setSfAccountantId($accountantId);
$account->setUsername($username);
$manager = new ObjectManager;
$manager->persist( $account ); //This throws the above mentioned exception
My thought is, the file ClientPortal\GenericBundle\Document\Accountant.php is being autoloaded as there is no exception thrown at the time of instantion of its object. But, there is something missing with configuration or mapping because of which doctrine does not know how to persist its object.
[Source code][1] Accountant class
GenericBundle(s) registered under AppKernel
new Website\GenericBundle\WebsiteGenericBundle(),
new Admin\GenericBundle\AdminGenericBundle(),
new ClientPortal\GenericBundle\ClientPortalGenericBundle(),
new TaxApp\GenericBundle\TaxAppGenericBundle(),
So, as I suggested in comments - try to add ClientPortal\GenericBundle\Document\ namespace to mappings in your doctrine config file, like that:
#...
orm:
auto_generate_proxy_classes: "%kernel.debug%"
mappings:
# ...
ClientPortalGenericBundle:
type: annotation
prefix: 'ClientPortal\GenericBundle\Document\'
dir: '%kernel.root_dir%/src/ClientPortal/GenericBundle/Document/'
#is_bundle: false
auto_mapping: true
Had the same issue with Symfony 4 while using multiple database connections. This one https://stackoverflow.com/a/55361742/2540699 helped me to solved my problem.
I bumped into this kind of message in my Symfony 6.1 project, using multiple entity managers, with one of the entity managers specified as default in doctrine.yaml:
doctrine:
orm:
default_entity_manager: general
entity_managers:
general:
# config for general
other_entity_manager:
# config for other entity manager
Everything was fine on my dev environment, but on production I got the error
Uncaught PHP Exception Doctrine\Persistence\Mapping\MappingException: "The class XXX was not found in the chain configured namespaces " at /opt/approot/current/vendor/doctrine/persistence/src/Persistence/Mapping/MappingException.php
Problem seemed to be that I have a when#prod: section in my doctrine.config.yml. It seems I had to repeat the default_entity_manager over there:
when#prod:
doctrine:
orm:
default_entity_manager: general
# other prod-specific configuration
This fixed it for me.
Update: This is probably related to this issue: https://github.com/symfony/symfony/issues/27769
I've gotten saltify to work on a fresh minion. I am able to specify a profile for the minion as well. However, I don't know how to assign custom grains to my minion during this process.
Here's my set up.
In /etc/salt/cloud.profiles.d/saltify.conf I have:
salt-this-webserver:
ssh_host: 10.66.77.99
ssh_username: opsuser
password: **********
provider: web-saltify-config
salt-this-fileserver:
ssh_host: 10.66.77.99
ssh_username: opsuser
password: **********
provider: file-saltify-config
In /etc/salt/cloud/cloud.providers I have:
web-saltify-config:
minion:
master: 10.66.77.44
driver: saltify
grains:
layers:
- infrastructure
roles:
- web-server
file-saltify-config:
minion:
master: 10.66.77.55
driver: saltify
grains:
layers:
- infrastructure
roles:
- file-server
When I run my command from my Salt master:
salt-cloud -p salt-this-fileserver slave-salttesting-01.eng.example.com
My /etc/salt/minion file on my minion looks like this:
grains:
salt-cloud:
driver: saltify
profile: salt-this-fileserver
provider: file-saltify-config:saltify
hash_type: sha256
id: slave-salttesting-01.eng.example.com
log_level: info
master: 10.66.77.99
I would really like it to also have:
grains:
layers:
- infrastructure
roles:
- file-server
I'd like for this to happen during the saltify stage rather than a subsequent step because it just fits really nicely into what I'm trying to accomplish at this step.
Is there a way to sprinkle some grains on my minion during "saltification"?
EDIT: The sync_after_install configuration parameter may have something to do with it but I'm not sure where to put my custom modules, grains, states, etc.
I found the grains from my cloud.providers file in /etc/salt/grains This appears to just work if you build your cloud.providers file in a similar fashion to the way I built mine (above).
I enabled debugging (in /etc/salt/cloud) and in the debugging output on the screen I can see a snippet of code that suggests that at some point a file named "grains" in the conf directory in git root may also be transferred over:
# Copy the grains file if found
if [ -f "$_TEMP_CONFIG_DIR/grains" ]; then
echodebug "Moving provided grains file from $_TEMP_CONFIG_DIR/grains to $_SALT_ETC_DIR/grains"
But, I am not sure because I didn't dig into it more since my grains are being sprinkled as I had hoped they would.
In Symfony's cookbook, there is a page entitled How to Simulate Authentication with a Token in a Functional Test. In it, it is said that:
The technique described in How to Simulate HTTP Authentication in a Functional Test is cleaner and therefore the preferred way.
Also, on the page that the quotation above links to, the documentation says:
The trick is to include the http_basic key in your firewall, along with the form_login key
This tells me that it is all right to have the form_login key, along with the http_basic key, and somehow http_basic should take precedence.
Here is my config_test.yml configuration file:
imports:
- { resource: config_dev.yml }
framework:
test: ~
session:
storage_id: session.storage.mock_file
profiler:
collect: false
web_profiler:
toolbar: false
intercept_redirects: false
swiftmailer:
disable_delivery: true
liip_functional_test:
cache_sqlite_db: true
doctrine:
dbal:
default_connection: default
connections:
default:
driver: pdo_sqlite
path: %kernel.cache_dir%/test.db
security:
firewalls:
default:
http_basic: ~
However, when I open my application in the test environment, I still get redirected to the login_form URL.
Why isn't setting the http_basic acting like the documentation says it should, namely it getting activated rather than form_login?
As commented here, having the code I pasted in my original question works just fine. The reason it is loading the login form is because I am not logging in via http_basic. In other words, when I have both form_login and http_basic enabled, I can login both by providing the PHP_AUTH_USER/PHP_AUTH_PASSWORD, and by logging in through the form. In effect, I don't need different security_*.yml files; I just need to add http_basic: ~ to the already-defined firewall.
Just split security.yml to security_test.yml and security_prod.yml.
In security_test.yml put default security configuration (as delivered with Symfony) or other one, which doesn't have firewall restrictions.
Create a specific config file for test environment, like config_test.yml with
imports:
- { resource: config.yml }
- { resource: security_test.yml }
note here config.yml itself doesn't have any security imports, because You will receive some Exception about overriding security directive or smth.
Create a separate config_prod.yml with
imports:
- { resource: config.yml }
- { resource: security_prod.yml }
Now You have separate security for test and prod environments.
If Your environment naming is good, then Kernel will pick config_test.yml only when tests are executed. For development environment Your should use config_dev.yml instead of config_test.yml
With Doctrine in Symfony2 there is a simple way to start a project with reverse-engineered Entities created from existing database schema. It is quite well documented here. There is not mentioned how to reverse-engineer data from a non-default database when using multiple databases (which is documented here).
I found the solution here, it works like this:
php app/console doctrine:mapping:convert --em="troller" --from-database yml ./src/NAMESPACE/NAMEBundle/Resources/config/doctrine/metadata/orm
However, I'm just getting the exception as if the second entity manager didn't exist. Even though I have config.yml according to docs.
[InvalidArgumentException]
Doctrine ORM Manager named "troller" does not exist.
Any ideas?
Did you specify an entity manager with "troller" name?
You can do this with a snippet of code like this (into app/config/config.yml file)
orm:
default_entity_manager: default
entity_managers:
default:
connection: default
mappings:
AcmeDemoBundle: ~
AcmeStoreBundle: ~
troller:
connection: troller
mappings:
YourTrollerBundle: ~
In this example, you've defined two entity managers called default and troller. The default entity manager manages entities in the AcmeDemoBundle and AcmeStoreBundle, while the troller entity manager manages entities in the YourTrollerBundle. You've also defined two connections, one for each entity manager.
Obiously define a new connection and entity manager, isn't enaugh: you have to specify "connection parameters" also (like db name, user, password, driver, and so on)
troller:
driver: "%database_driver2%"
host: "%database_host2%"
port: "%database_port2%"
dbname: "%database_name2%"
user: "%database_user2%"
password: "%database_password2%"
charset: UTF8