Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migration doesn't account for prefix when checking if migration table exists [bug] #3

Closed
fideloper opened this issue Jan 11, 2013 · 3 comments
Labels

Comments

@fideloper
Copy link
Contributor

Original bug found here: https://github.com/illuminate/database/issues/111 - Moved to his repo as per Taylor. Here's the original text:

I spoke with Machuga in IRC - It was suggested I create an issue.

Issue:

Error after first migration: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'up_migrations' already exists

Steps to reproduce:

  1. Fresh install of L4
  2. Add a prefix to database in database connection config (MySql)
  3. Create a migration $ php artisan migrate:make create_users_table --table=users --create
  4. Fill in some fields, run the migration $ php artisan migrate
  5. Attempt a migrate:refresh $ php artisan migrate:refresh
  6. ERROR: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'up_migrations' already exists

Relevant files:

I tracked this down to this file: Illuminate\Database\MigrationsDatabaseMigrationRepository::repositoryExists() and specifically within that, the call to return $schema->hasTable($this->table); here

The $this->table variable passed to hasTable() does not include the table prefix. Illuminate\Database\Schema\MySqlBuilder::hasTable($table) does not check for prefix either.

Unfortunately I'm not yet familiar with the code/convention to know where you'd prefer to look up the prefix. (Not sure what class should have that "knowledge")

@taylorotwell
Copy link
Member

OK, Thanks. We'll get it fixed.

@taylorotwell
Copy link
Member

Fixed.

@Darksoulsong
Copy link

I´m having this very same issue and I just downloaded the framework from the site.
I wonder if the fix was commited to the site version.

KluVerKamp added a commit to KluVerKamp/framework that referenced this issue Aug 29, 2015
Lately, I have upgraded my website from L 4.2.11 to the latest one. The Encryption cipher used before was MCRYPT_RIJNDAEL_128 which uses an IV with a length of 32. Since the payload in the cookies in users was encrypted using the old cipher, the EncryptCookies middleware threw an exception with this trace:

```
production.ERROR: exception 'ErrorException' with message 'openssl_decrypt(): IV passed is 32 bytes long which is longer than the 16 expected by selected cipher, truncating' in /home/www/MY/vendor/laravel/framework/src/Illuminate/Encryption/Encrypter.php:95
Stack trace:
#0 [internal function]: Illuminate\Foundation\Bootstrap\HandleExceptions->handleError(2, 'openssl_decrypt...', '/home/www/...', 95, Array)
laravel#1 /home/www/MY/vendor/laravel/framework/src/Illuminate/Encryption/Encrypter.php(95): openssl_decrypt('Dbyr0401XlXcY6N...', 'AES-256-CBC', 'VyZn2WxfW9UgMrI...', 0, 'h\x82\x9Co\t\x9Fqx\\\x84\x8B\x16\x8B\x82P...')
laravel#2 /home/www/MY/vendor/laravel/framework/src/Illuminate/Cookie/Middleware/EncryptCookies.php(95): Illuminate\Encryption\Encrypter->decrypt('eyJpdiI6ImFJS2N...')
laravel#3 /home/www/MY/vendor/laravel/framework/src/Illuminate/Cookie/Middleware/EncryptCookies.php(76): Illuminate\Cookie\Middleware\EncryptCookies->decryptCookie('eyJpdiI6ImFJS2N...')
laravel#4 /home/www/MY/vendor/laravel/framework/src/Illuminate/Cookie/Middleware/EncryptCookies.php(59): Illuminate\Cookie\Middleware\EncryptCookies->decrypt(Object(Illuminate\Http\Request))
laravel#5 [internal function]: Illuminate\Cookie\Middleware\EncryptCookies->handle(Object(Illuminate\Http\Request), Object(Closure))
laravel#6 /home/www/MY/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(124): call_user_func_array(Array, Array)
laravel#7 [internal function]: Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Object(Illuminate\Http\Request))
laravel#8 /home/www/MY/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(103): call_user_func(Object(Closure), Object(Illuminate\Http\Request))
laravel#9 /home/www/MY/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(122): Illuminate\Pipeline\Pipeline->then(Object(Closure))
laravel#10 /home/www/MY/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(87): Illuminate\Foundation\Http\Kernel->sendRequestThroughRouter(Object(Illuminate\Http\Request))
laravel#11 /home/www/MY/public/index.php(54): Illuminate\Foundation\Http\Kernel->handle(Object(Illuminate\Http\Request))
laravel#12 {main} 
```
This commit will allow the the decrypt method to handle non `Illuminate\Contracts\Encryption\DecryptException` exceptions. Since sometimes that class can't cover all the decryption issues since cookies can be set from other third parties in the browser.
christoph-kluge added a commit to christoph-kluge/framework that referenced this issue Apr 22, 2023
maddios pushed a commit to maddios/framework that referenced this issue Jul 13, 2023
added connectionName to queryLog
gonzalom pushed a commit to Hydrane/tmp-laravel-framework that referenced this issue Oct 12, 2023
gonzalom pushed a commit to Hydrane/tmp-laravel-framework that referenced this issue Oct 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants