Okay, I've got this problem:
I'm setting a boolean property with a default value in my migrations:
$table->boolean('is_public')->default(1);
It's working perfectly fine on my initial database, MySQL. I migrated the db and inserted manually, it gets inserted as true.
Problem is, though, when I run my tests that are configured with the sqlite in memory database, the default value doesn't get added. So this assert:
$this->assertEquals($league->is_public, 1);
...fails when it shouldn't.
Does anyone have any idea what I'm missing? Do I have to add something more so that the default value gets added to the database or this some kind of sqlite issue?
Change your migration to this.
$table->boolean('is_public',true);
Related
I am using laravel 5.5. * And I'm testing with vega scanner and getting SQL injection error.
How to fix this problem.?
this is the complete error specification
From my understanding, you are inserting directly in the database whatever comes from your request parameters, as the error says it is an "input validation error".
This is happening because you are not validating those inputs, in Laravel you can create validators, so that whenever you want to insert something, the values from the request are validated. If they are not validated, you can return a different response or prevent the controller from inserting data.
Here is the official documentation of Laravel, and it is really well explained. (I have browsed for your version, even though you can check the documentation for the latest version).
Hope I was able to help you.
the project I created with Strapi 3 Beta.17.5 did not create any table in the mysql database. During the installation but no error was displayed. What could be the problem?
Please see screenshot!
Thanks in advance
B. L.
The SSL was set to "true". After I changed it to "false", the project runs and has also created tables. :)
What I do not understand yet is that I entered "No" for SSL during installation, and SSL still set to "true".
I am newbie in using liquibase for database management. I am getting the following error while doing mvn install. I am not able to know where exactly i went wrong. Could someone please help me with the solution
Caused by: liquibase.exception.ValidationFailedException: Validation Failed:
1 changes have validation failures
'sql' is required, db/changelog/changes/v0001.sql::raw::includeAll
db.changelog-master.yaml
databaseChangeLog:
- includeAll:
path: db/changelog/changes/
liquibase folder structure
In liquibase whenever a migration is run it creates a hash value for each of the change log written in migration file. When the application is run for the first time entry is created for each change log with its hash values in the DatabaseChangelog Table.If a change is made to the existing change log which has been run once the hash value changes and a validation error is generated.
To fix this issue
you can revert the changes made to the change log after it was run for
the first time and create a new change log to accommodate the change
OR
delete the entries in the DatabaseChangeLog table for the particular
change log giving error along with the change associated with the
change log and rerun your migration.
I forgot to add query altogether. Just added the changeset!
The error you mentioned appears if you define changeset with empty SQL tag like this:
<changeSet id="test_users" author="test" dbms="h2">
<sql>
</sql>
</changeSet>
To fix it just remove this incomplete changeset or finish it by adding some SQL script you originally intended.
I have a strange issue with a Laravel 5.1 application.
Intermittently, it’s dropping session data. I’m detected this by writing some middleware that writes the contents of the session for that request to the log file. Although the session ID (Session::getId()) doesn’t change, the value of _token in the session data retrieved with Session::all() does.
As I say, this happens intermittently. I can refresh the same URL multiple times, and then randomly on one refresh the session data’s gone, and the _token value’s different from the previous requests.
What would cause this? I’ve also noticed the flash object isn’t in the “dropped” session data.
Below is a snippet of the log. You can see the content of the session_data key randomly changes “shape” in the last two lines, but the session ID remains constant.
Also, not sure if it’s pertinent, but I have DebugBar enabled.
UPDATE: Through debugging, I’ve found that on some page loads the session is completely empty, as in, no _token (hence a new one getting generated). Nothing.
If you're using the file driver, you could run into race conditions on concurrent requests. The file then gets truncated, Laravel can't read it, so it refreshes the session. Race conditions can also lead to a symptom where something you're putting to the session just doesn't get put. This tends to be random, so it's very hard to debug. According to the Laravel team, this is a known limitation of the file driver and it does not appear to be getting fixed, so I would suggest using a different driver. This would fix your issue of random session refreshes, but it still introduces a possibility of making a change to the session that doesn't get added. As far as I know, at this point with Laravel 5.1, you'll have to manage that yourself.
Somehow your session data is too long and being truncated. If you're using the database driver (haven't tested other drivers), and you try to save session data that's longer than the field length, then subsequent requests won't be able to pull from this session, and you'll wind up with a new session. If this issue is happening randomly with very short session data, then it's probably the cause listed above.
If you use Linux, Try using Redis (http://redis.io) as session / cache manager in laravel. I had some issues in the past with text / cookies and laravel in some servers. When I instaled Redis I had no problems anymore.
More info: https://laravel.com/docs/5.1/redis
Using a different driver like memcached did not solve the problem for me.
Here is a package that implements session locking which works and very simple to incorporate in your projects.
https://github.com/rairlie/laravel-locking-session
I just move my Magento store to my localhost environment for testing use, I also using Git to maintain code, but after I move all the files to my local environment, I can't login my admin page, but I can still see my frontend pages, and the git, the database, seems works well.
When I type a wrong admin/password to my admin page, it still gives me "Invalid password".
But when I enter the right one, it just refresh the page and stay at the login page, nothing happens.
Does anyone has met this problem before? Has any ideas?
Thanks in advance!
Although this question is old, all the above answers did not work for me until I did one additional thing.
Follow the very helpful answers already posted (summary):
Change your base_url to http://127.0.0.1/ for secure and unsecure path.
delete files in var/session and var/cache
alter your Varien.php file accordingly - depending on your version of Magento.
And then:
Finally, use http://127.0.0.1/your/site/folder/name/index.php/admin
It was the lack of the index.php/admin ( instead of using http://127.0.0.1/site/admin ).
I hope this helps someone else.
Recently started using Magento for a project and came across this issue. I was left frustrated by the fact there are at least ten or more different workarounds suggested on the net and it took a bunch of trial and error to find one that did the job. Seemingly some workarounds work for some versions and not for others. No one explained why or how the problem occurs and the most popular solutions involve hacking the code base or using a different url, which shouldn't be necessary.
The cleanest solution I found for Community Edition 1.9.1.1 was editing two config values in the database:
update core_config_data set value = NULL where path = "web/cookie/cookie_path";
update core_config_data set value = 0 where path = "web/cookie/cookie_httponly";
The cookie path is actually NULL by default on a fresh installation but it must either be NULL or empty string.
The behavior arises because some browsers including Chrome have issues creating cookies with a localhost domain, this means that when Magento calls session_start() the session identifier cookie never gets created and as a result information can not be passed from page to page. The login procedure is actually successful but the next request doesn't know about it, hence why you get redirected back to the login screen. There are no errors because Magento doesn't account for this edge case as a possibility.
If you do not provide a domain value when creating a cookie on localhost then the browser has no problem with it. Unfortunately just setting web/cookie/cookie_path to NULL is insufficient, because Magento's configuration class resolves this as an empty string which is enough for a real domain to be set later in the code:
if (isset($cookieParams['domain'])) {
$cookieParams['domain'] = $cookie->getDomain();
}
This method eventually uses the current HTTP host to resolve a real domain for the cookie, and the browser therefore wants nothing to do with it. However if we disable web/cookie/cookie_httponly then Magento will not perform this additional step, $cookieParams['domain'] is unset and no domain gets passed as a session parameter, thus allowing the session cookie to be created and things to function as they should.
Note that any time you modify the database configuration you must delete the contents of /var/cache/ for the changes to be reflected.
If like me you don't want to have to comment out code, or even make configuration changes, then I created an extension which overrides the getDomain() method shown above and returns null if we are on localhost, this should be somewhat more future proof and result in no collateral damage.
http://www.mediafire.com/download/q39p4k95s5tlght/LocalCookie.zip
Try deleting the contents of the cache folder /var/cache. Clear your browser cookies and try. Also, if you have copied down the database from your server, you may need to manually change the base urls (secure and non secure) as well as the cookie domain in the core_config_data table. Do this manually if you need to. e.g. web/unsecure/base_url with production value of http://www.mywebsite.com/ becomes "http://localhost/"
When ever I have had this it's because of this or cache. Ensure the cache folder is ignored in git hub if it's not already.
1.you need remove the cache
rm -rf var/cache/* var/session/*
2.change the domain form core_config_data
update core_config_data set value="http://127.0.0.1/" where path="web/unsecure/base_url";
update core_config_data set value="http://127.0.0.1/" where path="web/secure/base_url";
do these steps :
1: go through: xampp\htdocs\magento\app\code\core\Mage\Core\Model\Session\Abstract**
2: open **Varien.php file
3: make comment line number from 87 to 104 save it and try to login...
Had the same issue, but the fix was changing DB values:
UPDATE `core_config_data` SET `value` = 'http://127.0.0.1/example/' WHERE `path` = 'web/unsecure/base_url';
UPDATE `core_config_data` SET `value` = 'http://127.0.0.1/example/' WHERE `path` = 'web/secure/base_url';
Then in browser http://127.0.0.1/example/admin
Same problem! I fix my problem after remove/replace static domain in core_config_data Table
web/secure/base_url
web/secure/base_link_url
web/secure/base_skin_url
web/secure/base_media_url
For me, running it on IIS (I know, not officially supported):
Although other suggestions kind of worked I found the best solution was to enter a new A record for me domain like
127.0.0.1 local.example.com
Then in IIS add the binding
local.example.com
to my site and it worked perfectly.
I found there were errors when actually trying to login to the customer account more than admin but believe it still applies.