I don't know if I missed something while developing my application using Zend_Framwork, but here's my problem, I can't see any cookies, when I run my application on host server, but on my WAMP server everything worked well ..
I stock on sessions, user information to use it later, so on host server I can't login..
I use Zend_Auth and Zend_Acl, here's my bootstrap
$modelLoader = new Zend_Application_Module_Autoloader ( array ('basePath' => APPLICATION_PATH, 'namespace' => '', 'resourceTypes' => array ('form' => array ('path' => 'forms/', 'namespace' => 'Form_' ) ) ) );
$this->_acl = new Application_Plugin_Acl ();
$this->_auth = Zend_Auth::getInstance ();
I also use Zend_Auth getStorage()->write('...') to write infos in sessions.
And I have nothing related to sessions on my application.ini
So, it is WORKING on WAMP but, not on host servers. I presume you mean to say your VPS or dedicated server or say any cloud.
Zend_Auth uses $_SESSION and it has many functions operating on it. For instance, $_SESSION['Zend_Auth']['storage'] will give you information about what is in your hasIdentity() checking stuff.
So, what you should do is, get this pasted somewhere near the code and run it, just for your reference
echo '<pre>';
print_r($_SESSION);
Also, you can't see Cookies because they are session cookies which has 1 reference on client machine and rest all are on file system (if not configured) of the server.
Hope that helps.
Questions?
Related
my $jira = JIRA::REST->new({
url => 'https://something.com:8443',
username => 'username',
password => 'password',
session => 1,
});
The above code doesn't work and fails with below error probably due to port number at the end
Can't connect to something.com:8443 (Bad file descriptor)
is there a way/variable to mention the port number?
You need to add the setting ssl_verify_none => 1 into the hash used in your constructor.
The underlying LWP code allows you to not verify the certs of systems you connect to (which is not recommended for production), or it also allows you to specify a Certificate Authority (CA) cert that can be used to verify certs of systems you connect to. It looks like JIRA::REST has only supported the first option.
You might be better off just using the underlying LWP code, like this:
use LWP::UserAgent;
my $ua = LWP::UserAgent->new(
ssl_opts => { verify_hostname => 1, SSL_ca_file => 'myCA.cer' },
protocols_allowed => ['https'],
);
my $req = HTTP::Request->new(
GET => 'https://something.com:8443/rest/api/latest/issue/ABC-123',
);
$req->authorization_basic('username','password');
my $res = $ua->request($req);
It looks like JIRA::REST is just providing the raw JSON response to you anyway, so it's not really saving you all that much processing.
The main advantage of REST::Client is that it saves some stuff for you to add to each request implicitly. There's nothing particularly REST-y or helpful beyond sending a request and giving its response back to you.
The JIRA::Client has a few advantages, though, since it knows how to get a session cookie and properly attach files, and, more importantly, deal with paginated results. But often, when I'm doing things with Jira, I want more power.
Back in LWP's heyday, it was very frustrating to track transactions: a request-response pair. You could, but you had to manage it yourself. And, there weren't hooks in the process, so you had to create everything every time.
Then, LWP tried to work around some SSL issues (verifying host names, etc) and also split out LWP::Protocol::https. That's not a big deal when you understand that, but even though I do, it's something I have to remember every time I want to use LWP for something. There are reasons for everything that happened, but that doesn't make it any less annoying. That leads to the sort of work jimtut showed in his answer. Every time. But, it's a small speed bump on the way to insecurity.
I like Mojolicious much more because it represents complete transactions but also has hooks (well, events) that allow you to fiddle with things automatically while the process is chugging along.
Here's an example from Mojo Web Clients that shows me creating a user-agent for each service and setting some stuff for each transaction. I can adjust the request any way that I please before it does its work (and this is mostly what that REST::Client and JIRA::Client are doing for you):
my $travis_ua = Mojo::UserAgent->new();
$travis_ua->on( start => sub {
my( $ua, $tx ) = #_;
$tx->req->headers->authorization(
"token $ENV{TRAVIS_API_KEY}" );
$tx->req->headers->accept(
'application/vnd.travis-ci.2.1+json' );
} );
my $appveyor_ua = Mojo::UserAgent->new();
$appveyor_ua->on( start => sub {
my( $ua, $tx ) = #_;
$tx->req->headers->authorization(
"Bearer $ENV{APPVEYOR_API_KEY}" );
} );
In the Basic auth case, it's just a different value in that header:
use Mojo::Util qw(b64_encode);
my $jira_ua = Mojo::UserAgent->new();
$jira_ua->on( start => sub {
my( $ua, $tx ) = #_;
$tx->req->headers->authorization(
'Basic ' . b64_encode( join ':', $username, $password ) );
} );
Now, when I use those user-agents, the auth stuff is automatically added:
my $tx = $travis_ua->get( $url );
And, that $tx gives me access to the request and the response, so I don't need REST::Client to handle that for me either.
Since Mojolicious is handling all of this in one convenient package, I don't have to wrangle different objects. As such, there's not much left over that REST::Client can do for me.
I have two applications on the same domain, but they are both creating a plack_session every time the user logs in. It happens because application A overwrites application B's plack session.
It's a complex process to remove one of them and make them use one that is created by a central application, but for now, how can I change one of those 'plack_session' names to something like 'plack_session2' so they don't see each other?
I don't even know if it is possible.
Here is the document for Plack Session, but I can't see anything that can help me here.
As shown in the documentation you link to, the Plack session middleware is enabled with code like this:
builder {
enable 'Session',
state => Plack::Session::State->new;
$app;
};
Later in the same document, you'll find the documentation for the new() method:
new ( %params )
The %params can include session_key, sid_generator and sid_checker however in both cases a default will be provided for you.
session_key
This is the name of the session key, it defaults to 'plack_session'.
...
Putting all this together, I'd guess (and I haven't ever done this) that you can do what you want with code like this:
builder {
enable 'Session',
state => Plack::Session::State->new(
session_key => 'my_session_key',
);
$app;
};
Quick background: I'm fairly experienced with PHP, but needed to build my first RESTful API. I figured I'd try Laravel (5.2) and am starting to feel pretty comfortable with it.
I started adding auth to my project over the weekend and I am really struggling to get it working. I got the basic Laravel Auth middleware working quickly, but I think I need to be using OAuth2 for production (I will be building a mobile app that will connect up to this server). I'm using the Luca Degasperi OAuth2 package, which seems to be pretty popular.
I reviewed the actual documentation: https://github.com/lucadegasperi/oauth2-server-laravel/tree/master/docs#readme)
I also went through this tutorial: https://medium.com/#mshanak/laravel-5-token-based-authentication-ae258c12cfea#.5lszb67xb
And, most recently, I found this thread about the need to seed the OAuth tables before anything will work: https://github.com/lucadegasperi/oauth2-server-laravel/issues/56
That's all great, but there are some minor differences in the most recent distribution of Laravel. For example, /app/Http/Kernel.php is slightly different from what's shown in some of the examples I found because it now uses middleware groups. I thought I handled those differences correctly (I added the OAuthExceptionHandlerMiddleware class to the 'web' section of $middlewareGroups instead of $middleware). I got my seeder working (the current oauth_scopes table only allows you to supply a description, so I had to slim down what was provided in the third link above).
If I put a test route in my 'web' group in routes.php, I would have thought this would require OAuth because I added OAuth to the 'web' middleware group in Kernel.php. That's not the case. My route works with no authentication if I do that.
I then explicitly added the OAuth middleware to my test route as follows:
Route::get('tests/events', ['middleware' => 'oauth', function() {
$events = App\Event::get();
return response()->json($events);
}]);
That causes a 500 error ("ErrorException in OAuth2ServerServiceProvider.php line 126: explode() expects parameter 2 to be string, object given").
I'm to feel pretty lost. Each of these packages seems to be shifting so quickly that there's no complete documentation on how to get this up and running.
What else do I need to do to get this functioning?
The following link is what finally got me un-stuck:
https://github.com/lucadegasperi/oauth2-server-laravel/blob/master/docs/authorization-server/password.md
Now that I have it working, I'll try and make this a complete how-to FOR PASSWORD GRANT TYPES ONLY. I didn't play with other grant types. So this assumes you're building something like a RESTful API where users will connect to it with a client app that you're going to build. So users will create a user account in your system and then when they send a REST request, the OAuth2 package will authenticate them and send them a token to stay logged in.
I'm using Laravel 5.2 and already had the basic Auth package up and running. Be advised that a lot of these steps seem to change even with incremental releases of Laravel or the OAuth2 package.
The first part of getting this working is fairly well documented already (https://github.com/lucadegasperi/oauth2-server-laravel/tree/master/docs#readme), but here's a summary just in case...
Edit the require section of your composer.json file to look something like this:
"require": {
"php": ">=5.5.9",
"laravel/framework": "5.2.*",
"lucadegasperi/oauth2-server-laravel": "5.1.*"
},
Run composer update to download the package.
Open your config/app.php file and add the following two lines to the end of the providers section:
LucaDegasperi\OAuth2Server\Storage\FluentStorageServiceProvider::class,
LucaDegasperi\OAuth2Server\OAuth2ServerServiceProvider::class,
Also in config/app.php, add this line to the aliases array:
'Authorizer' => LucaDegasperi\OAuth2Server\Facades\Authorizer::class,
Now we start to do things a little differently from the documentation to accommodate the current version of Laravel...
Open app/Http/Kernel.php. Laravel now uses groups and it didn't used to. Update your $middlewareGroups to look like this:
protected $middlewareGroups = [
'web' => [
\App\Http\Middleware\EncryptCookies::class,
\Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
\Illuminate\Session\Middleware\StartSession::class,
\Illuminate\View\Middleware\ShareErrorsFromSession::class,
//Added for OAuth2 Server
\LucaDegasperi\OAuth2Server\Middleware\OAuthExceptionHandlerMiddleware::class,
//Commented out for OAuth2 Server
//\App\Http\Middleware\VerifyCsrfToken::class,
],
'api' => [
'throttle:60,1',
],
];
Also in app/Http/kernel.php, update $routeMiddleware to look like this:
protected $routeMiddleware = [
'auth' => \App\Http\Middleware\Authenticate::class,
'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class,
'can' => \Illuminate\Foundation\Http\Middleware\Authorize::class,
'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class,
'throttle' => \Illuminate\Routing\Middleware\ThrottleRequests::class,
//Added for OAuth2 Server
'oauth' => \LucaDegasperi\OAuth2Server\Middleware\OAuthMiddleware::class,
'oauth-user' => \LucaDegasperi\OAuth2Server\Middleware\OAuthUserOwnerMiddleware::class,
'oauth-client' => \LucaDegasperi\OAuth2Server\Middleware\OAuthClientOwnerMiddleware::class,
'check-authorization-params' => \LucaDegasperi\OAuth2Server\Middleware\CheckAuthCodeRequestMiddleware::class,
'csrf' => App\Http\Middleware\VerifyCsrfToken::class,
];
You now have to set up your grant types. You used to do this all in one place in config\oauth2.php using an array with a closure for callback. With the most recent version of the OAuth2 server package, you can't use a closure for callback anymore. It has to be a string. So your grant_types should look something like this:
'grant_types' => [
'password' => [
'class' => '\League\OAuth2\Server\Grant\PasswordGrant',
'callback' => '\App\PasswordGrantVerifier#verify',
'access_token_ttl' => 3600
]
]
access_token_ttl is the duration that an auth token will be good for (in seconds). The main package documentation uses 3600 (1 hour) by default. You might want to try 604800 (1 week) instead -- at least during testing.
You now need to create the PasswordGrantVerifier class and verify method that you just called in the code section above. So you create a file App/PasswordGrantVerifier.php and use the following code (which is basically what used to go in the closure for callback).
<?php
namespace App;
use Illuminate\Support\Facades\Auth;
class PasswordGrantVerifier
{
public function verify($username, $password)
{
$credentials = [
'email' => $username,
'password' => $password,
];
if (Auth::once($credentials)) {
return Auth::user()->id;
}
return false;
}
}
You will need at least one row in the oauth_clients table before OAuth2 will work. You can insert something manually or create a seeder. To create a seeder, modify database/seeds/DatabaseSeeder.php and add the following to the end of the run() method:
$this->call(OAuthClientsTableSeeder::class);
Now create a file called database/seeds/OAuthClientsTableSeeder.php and enter something like this:
<?php
use Illuminate\Database\Seeder;
class OAuthClientsTableSeeder extends Seeder
{
/**
* Run the database seeds.
*
* #return void
*/
public function run()
{
//Add sample users
$oAuthClients = array(
array(
'id' => 'TEST_ENVIRONMENT',
'secret' => 'b17b0ec30dbb6e1726a17972afad008be6a3e4a5',
'name' => 'TEST_ENVIRONMENT'
)
);
foreach ($oAuthClients as $oAuthClient) {
App\OAuthClient::create($oAuthClient);
}
}
}
Run php artisan vendor:publish to publish the package configuration and migrations. Run php artisan migrate to set up the billion-or-so new tables for OAuth. Run php artisan db:seed to seed your database.
You can now set up some test routes in app\Http\routes.php. They should look something like this:
Route::post('oauth/access_token', function() {
return Response::json(Authorizer::issueAccessToken());
});
Route::group(['middleware' => 'oauth'], function () {
Route::get('authroute', function() {
//OAuth will be required to access this route
});
Route::post('postwithauth', function(Request $request) {
$userID = Authorizer::getResourceOwnerId();
$input = $request->input();
return response()->json(array('userID' => $userID, 'input' => $input));
});
});
Route::get('noauthroute', function () {
//No authorization will be required to access this route
});
Pay close attention to the postwithauth route I included above. The OAuth2 package recently changed how you access the user's ID and it took me quite a while to figure out how to get it.
Now that it's time for testing, point your browser to localhost:8000 (or whatever the path is for your test environment) and create a user account for yourself (this step just uses the standard Laravel Auth package).
Go into your HTTP client (I'm currently using Paw and I like it). Go to request->authorization->OAuth2 to set up authorization for the route you're going to test. For Grant Type, select Resource Owner Password Credentials. If you used the seed example I provided above, the Client ID is TEST_ENVIRONMENT, the Client Secret is b17b0ec30dbb6e1726a17972afad008be6a3e4a5, enter the username (email) and password you created through the web Auth interface, your Access Toekn URL will be something like localhost:8000/oauth/access_token (depending on how you set up your test environment), leave Scope blank, and Token should say Bearer. Click on Get Access Token then say Use Access Token when prompted.
That should be it!
I have tow cascading Plack middleware applications(app1, app2), app1 is the front application. I followed these tutorials:
http://advent.plackperl.org/2009/12/day-10-using-plack-middleware.html
http://advent.plackperl.org/2009/12/day-19-cascade-multiple-applications.html
This is my code:
use Plack::App::Cascade;
use Plack::App::URLMap;
use lib "/var/www/app1/lib",
"/var/www/app2/lib";
use app1;
use app2;
my $app1 = app1->psgi_app(#_);
my $app2 = app2->psgi_app(#_);
my $app_map1 = Plack::App::URLMap->new;
$app_map2->mount( '/' => $app1 );
my $app2 = Plack::App::URLMap->new;
$app2->mount( '/app2' => $app2 );
Plack::App::Cascade->new(apps => [ $app_map1, $app_map2 ])->to_app;
Until now everything is ok, I added also the authentication functionality, and for that i used these two catalyst modules: Catalyst::Plugin::Authentication and Catalyst::Plugin::Authorization::Abilities.
The authentication part is working fine for the two applications (user logged from app1), but I got a problem for the authorization part just for app2. When I try to figure out, it was the context variable $c. The app1 $c variable was not the same as app2. After authentication (from app1) I got a user object $c->user, but for the second application I had a new $c created and the $c->user is not found.
So how can these two applications get the same context $c?
I find the solution but before that let me explain the situation:
PSGI with muti middelware applications have same limitation. Each middleware behaves as a separate application and each one create its own session. In case, we have the authentication feature(applied for all middelware) we got a prob here. like the example above, the app1 had the session of the authenticated user but app2 had just an anonymous session.
So to fixe it. I create a shared memory to store sessions. For that, me must change Catalyst::Plugin::Session::Store::File with Catalyst::Plugin::Session::Store::FastMmap for app1 and app2.
Then add this config in app2.pm:
'Plugin::Session' => {
cookie_name => 'app1_session',
storage => '/tmp/app1/session_data',
}
I'm building an app with Mojolicious Lite and I'm looking to give myself a way to watch any and all data about the active sessions. I'm mostly doing this because this is my first foray into using sessions with Mojolicious Lite, and I want to watch what's going on under the hood.
A couple notes:
I'm pretty new to Mojolicious, as you might guess by the fact that I'm using Mojolicious Lite. Any Mojolicious Lite apps I've written before have been pretty trivial, so my familiarity with it is not deep.
For that matter, I'm still 'early intermediate, at best' with perl, so poking around the inner workings of anything OO in perl is largely foreign territory for me.
That said, I made myself a few little routes like so:
get '/firstpage' => sub{
my $self = shift;
my $usr = $self->session(user => 'first_user');
$self->render(text => $usr);
};
get '/secondpage' => sub{
my $self = shift;
my $usr = $self->session(user => 'second_user');
$self->render(text => $usr);
};
get '/sessions' => sub{
my $self = shift;
$self->render(text => Dumper(app->sessions));
};
I'm working off the assumption that, after I visit the first two urls, Mojolicious will have 'some' data somewhere that would confirm that it knows about first_user and second_user. (I could also be totally off base in my understanding of how to use Mojolicious Lite sessions...honestly, from the documentation, I'm not really sure.)
Sadly, /sessions just shows me the contents of the Mojolicious::Sessions object:
$VAR1 = bless( {
'cookie_path' => '/',
'secure' => 0,
'cookie_name' => 'mojolicious',
'default_expiration' => 3600
}, 'Mojolicious::Sessions' );
But I'm assuming that, somewhere, I can get to a hash of all of the session-related data that Mojolicious has. I've been poking around the documentation for a while but I have yet to find any leads.
Any insight?
I'm working off the assumption that, after I visit the first two urls, Mojolicious will have 'some' data somewhere that would confirm that it knows about first_user and second_user. (I could also be totally off base in my understand of how to use Mojolicious Lite sessions...honestly, from the documentation, I'm not really sure.)
Yeah, I think you're missing the point of sessions. The server/app doesn't remember the state of every user who visits. To allow it to look as if it did, we have cookies. A session is a per-client persistence thing.
Session information is just a hashreference, encoded as JSON and stored in a cookie on the client side. This is useful for remembering that you are logged in, as what username, perhaps an arrayref of things in your shopping cart. When you request a page, this cookie is sent back to the server, which can access the data and prepare the response for you knowing the state of your session.
As such there is no record of "active sessions". All that information is distributed amongst all the clients.
If you would like to get a better idea of what's going on, may I recommend tempire's plugin Mojolicious::Plugin::ConsoleLogger which for the current request shows all of the relevant information (session, stash etc) in your browser's javascript console.
Here is an example.
#!/usr/bin/env perl
use Mojolicious::Lite;
#plugin 'ConsoleLogger'; # if desired
any '/' => sub {
my $self = shift;
my $name = $self->session('name') || 'Unknown'; # get the name from the session
$self->render( text => "Hello $name" );
};
any '/name/:name' => sub {
my $self = shift;
my $name = $self->stash('name'); # get name from path
$self->session( name => $name ); # and store it in the session
$self->redirect_to('/');
};
any '/logout' => sub {
my $self = shift;
$self->session( expires => 1 );
$self->redirect_to('/');
};
app->start;
If you visit /name/ghorahn it will store your name in a cookie. From then on, every time you visit / it will say hello to you until:
Your session expires (default 1 hour from your last visit)
You change your name via /name/whatever
You visit /logout to manually expire the session
You will notice that another user (either on another computer or even a different browser on your same computer) may have a different name, but both are persistent. That is what a session is for. :-)