I'm trying to integrate CKFinder with Laravel, and I'm about 95% there. I can get everything to work, except for the CheckAuthentication function - I have to make it return true regardless for the upload to work.
What I've tried doing is bootstrapping Laravel in the config.php file and then checking if a user is logged in, like below:
public/packages/ckfinder/config.php
<?php
/*
* ### CKFinder : Configuration File - Basic Instructions
*
* In a generic usage case, the following tasks must be done to configure
* CKFinder:
* 1. Check the $baseUrl and $baseDir variables;
* 2. If available, paste your license key in the "LicenseKey" setting;
* 3. Create the CheckAuthentication() function that enables CKFinder for authenticated users;
*
* Other settings may be left with their default values, or used to control
* advanced features of CKFinder.
*/
/** RIPPED FROM public/index.php **/
/*
|--------------------------------------------------------------------------
| Register The Auto Loader
|--------------------------------------------------------------------------
|
| Composer provides a convenient, automatically generated class loader
| for our application. We just need to utilize it! We'll require it
| into the script here so that we do not have to worry about the
| loading of any our classes "manually". Feels great to relax.
|
*/
require __DIR__.'/../../../bootstrap/autoload.php';
/*
|--------------------------------------------------------------------------
| Turn On The Lights
|--------------------------------------------------------------------------
|
| We need to illuminate PHP development, so let's turn on the lights.
| This bootstraps the framework and gets it ready for use, then it
| will load up this application so that we can run it and send
| the responses back to the browser and delight these users.
|
*/
$app = require __DIR__.'/../../../bootstrap/start.php';
/** END public/index.php **/
/**
* This function must check the user session to be sure that he/she is
* authorized to upload and access files in the File Browser.
*
* #return boolean
*/
function CheckAuthentication()
{
// WARNING : DO NOT simply return "true". By doing so, you are allowing
// "anyone" to upload and list the files in your server. You must implement
// some kind of session validation here. Even something very simple as...
return Auth::check();
}
This always returns false, though. I've also tried directly using Laravel's Session to set a variable to true when someone logs in, and false when they log out, and then checking that in the config.php file, but it always returns the default value in Session::get("IsAuthorized", false);. Can anyone offer some guidance as to -
1) How to authenticate whether the user should be allowed to upload?
2) Why bootstrapping Laravel in another file seems to cause it to use a separate session, even when it's loading the same files?
I tried integrating simogeo's Filemanager and KCFinder into a Laravel project and I found the same problem.
With this code, it's possible to share Laravel's session and check authentication from external projects:
https://gist.github.com/frzsombor/ddd0e11f93885060ef35
From my experience, starting from 4.1.28, Application::boot() does not initialize sensitive session data anymore.
So if you're integrating 3rd party library, which needs external authentification check through sessions, simple checking Auth::check() will not work. However, we can still use old $_SESSION variable.
E.g. this one will not work:
require __DIR__.'/../bootstrap/autoload.php';
$app = require_once __DIR__.'/../bootstrap/start.php';
$app->boot();
return Auth::check();
Session variables for Auth::check() to work are initialized only in $app->run() sequence. But in that case, routing will take place and probably you will get unrecognized page... unless you're using dedicated Laravel package for this.
This one - below - still works:
// Somewhere in your app - e.g. in filters.php, "auth"/"guest" filters declaration
if (session_id() == '') {
#session_start();
/* or Session:start(); */
}
$_SESSION['isLoggedIn'] = Auth::check() ? true : false;
Then in your case, function would be simple as:
function CheckAuthentication()
{
if (session_id() == '') {
#session_start();
}
return isset( $_SESSION['isLoggedIn'] ) && $_SESSION['isLoggedIn'] == true;
}
N.B. If you can use Ajax calls for authorization checks, you can still make a custom API with JSON request to user-logged (as an example) to see if user is authentificated.
To answer your second question - it's not so simple as it sounds. Laravel, as a default, uses file system for session storage. While session data is still accessible, it is encrypted - unless you will write your own Session manager, you can't extract anything from there easily.
Related
I am developing on an old project that uses Symfony 2.8.
I develop locally and in the Twig I can correctly use {{app.user.username}} or other like {{app.session...}}.
When I deploy it in a staging environment those values are always blank.
Then if I deploy it in production, the global app variable works fine as in local.
Is it possible that the staging env is configured to not to initialize the app variable? Where can I take a look?
Plus, a strange thing. The same behavior happens also if I make a custom, loading session data from the controller and passing them to the view.
Controller
$session = $this->get('session');
$content = $this->render(
'blocks/logged_user_menu.html.twig',
[
'access_token_sc' => $session->get('access_token')
]
);
View
{{ access_token_sc }}
I've read that I could take a look at Security config but doesn't seem to help.
Thanks to #john Smith comment I found out that this kind of problem is related to session.storage_id in the config.yml file. In my case the test config file was using mock_file that inhibited the session behavior.
Leaving here the explanation for reference:
MockFileSessionStorage class
namespace Symfony\Component\HttpFoundation\Session\Storage;
/**
* MockFileSessionStorage is used to mock sessions for
* functional testing when done in a single PHP process.
*
* No PHP session is actually started since a session can be initialized
* and shutdown only once per PHP execution cycle and this class does
* not pollute any session related globals, including session_*() functions
* or session.* PHP ini directives.
*
* #author Drak <drak#zikula.org>
*/
class MockFileSessionStorage extends MockArraySessionStorage
{ ...
Background: I am trying to set up single sign on (SSO) for users such that they can authenticate to my website and not have to authenticate a second time to our third-party MSP's website. Ideally, the user clicks a link on our website and is taken to the third-party site already logged in and landing on the dashboard (if the account doesn't exist, it is created during this step). We are not using SAML for authentication as a security feature, so all that we need the SAML code for is just producing cookies that prevent the user from having to log in again when he/she gets to our vendor's site. This third party MSP does not support authentication via API or web service and therefore I have been tasked with implementing SAML, their only supported SSO method. I am new to SAML (but not PHP or development) and have been learning as I go. I am told it will support the goals described above.
I initially tried using LDAP as the authentication source as this is what I use for authentication to my website, but this resulted in me getting directed to a login page with no discernible way to instead just pass parameters to SimpleSAMLphp to tell it "the user is already authenticated, all I need you to do is give me valid cookies so I can get past the third party website's authentication checks".
So I switched to writing a custom authentication module. I opened up the GitHub for SimpleSAMLphp and used the "UserPassBase" class as an example to create my own authentication module that inherits from the "Source" class. Because I don't need to re-authenticate the user against LDAP a second time since they're already logged in to our website, I created a simple "authenticate" function that just sets the $state['Attributes'] array.
Here is the code for my custom module:
<?php
namespace SimpleSAML\Module\productauth\Auth\Source;
use SimpleSAML\Auth;
/**
Author: Joey
Class developed to be used as a custom authentication module for simpleSAMLphp. This class will take an existing session from a product website and use it to create a SAML session and redirect to a website.
**/
class ProductAuth extends \SimpleSAML\Auth\Source {
const STAGEID = '\SimpleSAML\Module\productauth\Auth\ProductAuth.state';
const AUTHID = '\SimpleSAML\Module\productauth\Auth\ProductAuth.AuthId';
private $user;
public function __construct($info, $config) { // parameters aren't used, just filler from base class
$info = array("AuthId" => "productauth");
parent::__construct($info, $config);
}
public function login($user, $redirectURL) {
$this->user = $user; // normally I'd set this in the constructor, but the overload has my hands tied as far as function definitions go
$this->initLogin($redirectURL); // calls authenticate function and then, if no exceptions, parent::loginCompleted which redirects to the given URL
}
public function authenticate(&$state) { // called by parent::initLogin
$state[self::AUTHID] = $this->authId;
$state['Attributes'] = [
'uid' => [$this->user->uid],
'givenName' => [$this->user->givenName],
'sn' => [$this->user->sn],
'mail' => [$this->user->mail]
];
$id = Auth\State::saveState($state, self::STAGEID);
}
}
?>
I am calling it from a controller class on my website:
private function goToTrainingSite() {
require_once("../third-party-libs/simplesamlphp/_include.php");
global $TRAINING_URL;
$user = $_SESSION['subject']->user;
$samlObj = new SimpleSAML\Module\productauth\Auth\Source\ProductAuth(array(), array());
$samlObj->login($user, $TRAINING_URL);
}
I mimicked the flow of the "UserPassBase" class (https://github.com/simplesamlphp/simplesamlphp/blob/master/modules/core/lib/Auth/UserPassBase.php), but it seems that despite all of my authentication working and setting a SimpleSAMLAuth cookie, when the parent::loginCompleted function in the "Source" class (https://github.com/simplesamlphp/simplesamlphp/blob/master/lib/SimpleSAML/Auth/Source.php) runs, it redirected me to the third party site. I then see the following in the logs:
SAML2.0 - IdP.SSOService: incoming authentication request: [REDACTED DATA]
Session: 'productauth' not valid because we are not authenticated.
I have been trying for 3 days to figure out why it seems as though despite setting SimpleSAML session cookies with a completed, successful authentication, that upon receiving the auth request from the SP, my SimpleSAMLphp code just pretends to not know about the completed auth and tries to authenticate again... but because it is not being called from my code, it doesn't have access to the $user variable which contains all of the attributes I need to place on the user when he/she authenticates to this third party website. It seems that when it receives an authentication request, my SimpleSAMLphp installation starts a new session and tries a brand new authentication.
I have delved into a lot of the code of SimpleSAMLphp and tried to understand what is going on, but it seems that there is just no reasonable way to authenticate by calling an authentication source from PHP code and being able to skip the SP-initiated authentication. I have tried:
Using the SimpleSAML API (https://simplesamlphp.org/docs/stable/simplesamlphp-sp-api) to call my authentication source, but there seems to be no way to pass that $user variable I need the attributes from.
Trying to load the cookies in the "Session" class when it is checking for valid sessions... but it seems like the cookies from the successful auth session initiated by my code are just gone and nowhere to be found.
I decided to stop focusing on trying to get the $user variable and the data I needed to the second authentication, and instead focus on WHY the second authentication was even happening. I looked at the cookies and thought about how the data was being retrieved, and made a correct hunch that our application's custom session handler might be at fault for SimpleSAMLphp's inability to recognize the first authentication. Our custom session handler stores our sessions in the database, but SimpleSAMLphp expects to use the default PHP session handler to manage its session. Therefore, my first authentication was being sent to the database and when SimpleSAMLphp started looking for it where PHP sessions are usually stored, it didn't see it and assumed it needed to kick off another authentication session from scratch.
Using SimpleSAMLphp's documentation for service providers and a lot of my own debugging, I changed the function in my controller like so:
private function goToTrainingSite() {
require_once ("../third-party-libs/simplesamlphp/_include.php");
global $TRAINING_URL;
$joeySiteSession = $_SESSION;
$user = $_SESSION ['subject']->user; // save user to variable before the Joey's Site session is closed
session_write_close (); // close Joey's Site session to allow SimpleSAMLphp session to open
session_set_save_handler ( new SessionHandler (), true ); // stop using SessionHandlerJoey and use default PHP handler for SimpleSAMLphp
$samlObj = new SimpleSAML\Module\joeysiteauth\Auth\Source\JoeySiteAuth ( array (), array () );
$samlObj->login ( $user, function () { return;} ); // use custom authentication module to set atttributes and everything SimpleSAMLphp needs in the auth session/cookie
$session = \SimpleSAML\Session::getSessionFromRequest ();
$session->cleanup (); // must call this function when we are done with SimpleSAMLphp session and intend to use our Joey's Site session again
session_write_close ();
$_SESSION = $joeySiteSession; // restore Joey's Site session
header ( "Location: {$TRAINING_URL}" );
}
In my local environment I want all logs (all flags) to go the browser's console (BrowserConsoleHandler) and then to the default StreamHandler.
In production, I want the errors and other critical messages to go to an e-mail then stored in the database or (if fails) to a log file (default StreamHandler)
I want to set up this in a global middle-ware that I have created, which looks like this now:
<?php
namespace App\Http\Middleware;
use Closure;
use Illuminate\Support\Facades\App;
use Illuminate\Support\Facades\Log;
use Monolog\Logger;
use Monolog\Handler\BrowserConsoleHandler;
class GlobalConfig
{
/**
* Handle an incoming request.
*
* #param \Illuminate\Http\Request $request
* #param \Closure $next
* #return mixed
*/
public function handle($request, Closure $next)
{
// Get Monolog instance
$monolog = Log::getMonolog();
// In local environment the logs will be shown on browser
if (App::environment('local')) {
// Show logs in browser console
$monolog -> pushHandler(new BrowserConsoleHandler());
} else {
// Here we set up for production
}
Log::debug("Browser handler working");
return $next($request);
}
}
This doesn't work (the message is stored in the log file only, not shown on console). What I can't figure out is how to let the Log facade know about this new handler, because here, as is obvious, things are only changed within the function's scope. I know I can do it in bootstrap/app.php but isn't it to early to get the environment? Also, if I need to save logs to the database, it must already be connected, I guess
You can try to do next in bootstrap\app.php
if(env('APP_ENV') == 'local') {
$app->configureMonologUsing(function($monolog) use ($app) {
$monolog->pushHandler(
$handler = new \Monolog\Handler\RotatingFileHandler(
$app->storagePath().'/logs/laravel.log',
$app->make('config')->get('app.log_max_files', 30),
\Monolog\Logger::DEBUG
)
);
$handler->setFormatter(new \Monolog\Formatter\LineFormatter(null, null, true, true));
$monolog->pushHandler(new \Monolog\Handler\NativeMailerHandler(
'to#mail.com',
'Log::error!',
'from#mail.com'
));
});
}
Idea here is to fully control your logging on live/local. Bad news - configureMonologUsing replace all default laravel loggers, so you need to configure all your logs manually here.
Middleware isn't really the place for this, unless you wanted to actually make a particular log entry at some point in the request cycle.
Your call to pushHandler belongs in bootstrap/app.php (in Laravel 5.2), according to the docs.
I would think it would be possible to extract this logic out into a provider in case it becomes complicated and you need to move it out of bootstrap/app.php
solution here
BrowserConsoleHandler sends the script snipped after finishing the php
script by register_shutdown_function(). At this time, Laravel already
sent the full response to the browser. So the script snipped from
BrowseConsoleHandler gets generated but never sent to the browser.
I'm using Laravel 5.1 and trying to set different logging logic for a development and production environment.
Throughout my application I am using the Log facade with most of the following different methods:
Log::emergency($error);
Log::alert($error);
Log::critical($error);
Log::error($error);
Log::warning($error);
Log::notice($error);
Log::info($error);
Log::debug($error);
However, in my production environment, I would like to only log anything that is an Error, Critical, Alert or Emergency priority and ignore log requests with lower priority.
I couldn't find anything in the documentation or by exploring the code (both Log facade and the Monolog class).
My current thought is to create a custom wrapper around the Log facade that simply checks the environment and ignores anything below 400 (Monolog level for Error). Basically I would create a threshold variable in the environment file and anything below it will simply not be logged to the files.
Before I do so, I wanted to ask the community if there is an existing method/configuration for that which I could use, so that I don't re-invent the wheel.
If not - what would be the best approach?
This gist shows a more comfortable answer, as is not dependent on the
chosen handler.
I'm just providing the essential part in an answer here in case the above link gets deleted in some time.
In the AppServiceProviders' register method:
/**
* Register any application services.
*
* #return void
*/
public function register()
{
//
$monolog = Log::getMonolog();
foreach($monolog->getHandlers() as $handler) {
$handler->setLevel(Config::get('app.log-level'));
}
}
Then just add an additional key to your config/app.php:
'log-level' => 'info', // or whatever minimum log level you would like.
Add the following code to your AppServiceProvider::register():
$this->app->configureMonologUsing(function ($monolog) {
$monolog->pushHandler(
$handler = new RotatingFileHandler(
$this->app->storagePath() . '/logs/laravel.log',
$this->app->make('config')->get('app.log_max_files', 5),
$this->app->make('config')->get('app.level', 'debug')
)
);
$handler->setFormatter(new LineFormatter(null, null, true, true));
});
This recreates the logic that Laravel does when setting up the daily handler, but adds passing level to the handler.
You can set your minimum logging level by setting level value in your config/app.php:
'level' => 'debug', //debug, info, notice, warning, error, critical, alert, emergency
This is a bit of a workaround and each type of handler would need to be set up separately. I'm currently working on a pull-request to Laravel that would add setting minimum debug level from the config file without writing a line of code in your AppServiceProvider.
The code above hasn't been tested, so let me know if you see any typos or something doesn't work properly and I'll be more than happy to make that work for you.
I'm developing my first Laravel package in workbench to solve a business need which is to integrate the Authorize.net SDK for our systems billing transactions.
I've got most of my code now working and I can call the SDK functions via my custom facade like so AuthorizeMe::authorizeAndCapture(); My issue is the Authroize.net SDK requires use of defined variables. Their example usage is as follows:
define("AUTHORIZENET_API_LOGIN_ID", "YOURLOGIN");
define("AUTHORIZENET_TRANSACTION_KEY", "YOURKEY");
define("AUTHORIZENET_SANDBOX", true);
$sale = new AuthorizeNetAIM;
$sale->amount = "5.99";
$sale->card_num = '6011000000000012';
$sale->exp_date = '04/15';
$response = $sale->authorizeAndCapture();
if ($response->approved) {
$transaction_id = $response->transaction_id;
}
I would like to 1) store the defined variables in the packages config.php file, 2) I would like to make it so if I do publish the package other users can simply publish the config file to their app/config/packages folder so they can simply put in their unique api info.
I have tried to store the API variables in the config.php array as follows:
return array(
/*
|--------------------------------------------------------------------------
| Define credentials
|--------------------------------------------------------------------------
|
| Your credentials for both live environment and sandbox
|
*/
// Live environment
'LIVE_LOGIN_ID' => 'YOUR ID',
'LIVE_TRANSACTION_KEY' => 'YOUR KEY',
// Sandbox evnironment
'SANDBOX_LOGIN_ID' => 'YOUR SANDBOX ID',
'SANDBOX_TRANSACTION_KEY' => 'YOUR SANDBOX KEY',
/*
|--------------------------------------------------------------------------
| Define environment
|--------------------------------------------------------------------------
|
| Dictates if we're in sandbox mode or live mode
|
*/
'SANDBOX' => true,
);
I don't believe defined variables can be set from within a class so I'm not sure how to use the config file to accomplish my needs.
For example, something like this doesn't seem to work:
class MyClass {
public function __construct($app=null)
{
$this->app = $app ?: app();
}
public function billClient()
{
define("LIVE_LOGIN_ID", $this->app['config']->get('LIVE_LOGIN_ID'));
}
}
Lastly, I don't want to re-write the vendors package to simply work with my implementation as I feel it's important to make sure my package wrapper just sits on top so that it can pull in any future updates.
Store your static data that can change depending on what server your software is running on inside of the environment root-level configuration file. I would suggest doing this also to avoid the possibility of your API keys getting committed into source control (which could potentially be damaging). You can also leverage this to have different configuration values in different environments. Quoting from that linked to manual entry:
For "real" applications, it is advisable to keep all of your sensitive configuration out of your configuration files. Things such as database passwords, Stripe API keys, and encryption keys should be kept out of your configuration files whenever possible
The general practice is to keep these defined in a config file named .env.{environment name}.php which does not get checked in to source control. You can also specify them inside of the virtual host for the site if that works better for you, with e.g. SetEnv directives for Apache.