Beego must have one register DataBase alias named `default` - go

In the production server with Beego I get
must have one register DataBase alias named default
I know the db connection credentials work in the server but whenever I do restful request I get this error and the Beego server crashes.
Is there a reason why this is happening?
Below is the code inside main.go init function:
orm.RegisterDriver("postgres", orm.DR_Postgres)
orm.RegisterDataBase("default", "postgres",
fmt.Sprintf("postgres://%s:%s#%s/%s?port=%i",
pgUser, pgPass, pgHost, pgDb, pgPort))

Can you provide a sample of your code?
Based on the error message you have provided, you may not have registered a database with alias default using orm.RegisterDataBase. Here's an example which I have taken from the documentation:
// param 1: Database alias. ORM will use it to switch database.
// param 2: driverName
// param 3: connection string
orm.RegisterDataBase("default", "mysql", "root:root#/orm_test?charset=utf8")
In beego, it is common to register the driver and the database in init of main.go (example).

Related

Passport - Create client credentials grant client programmatically

The documentation Here suggests php artisan passport:client --client for creating a client, but I want to do it using a controller, or ideally, using the native JSON apis provided by passport.
Is that possible at all or will I have to override the methods in Passport::client ?
Old question, but here's a 2021 answer for people finding this on Google.
I find calling Artisan commands from code unsavory, especially as #kishore-kadiyala mentioned because you get back printed output, rather than code.
Instead, you can use the Laravel\Passport\ClientRepository class to create a client directly:
use Laravel\Passport\ClientRepository;
// ... snip ...
$clients = App::make(ClientRepository::class);
// 1st param is the user_id - none for client credentials
// 2nd param is the client name
// 3rd param is the redirect URI - none for client credentials
$client = $clients->create(null, 'My Client Name', '');
Here, $client is a Laravel\Passport\Client instance directly. This is exactly how the Artisan command creates the clients anyway.
You can do
Artisan::call('passport:client --client');
Look at Artisan

Trying to set up CAS with my Laravel project

I am using subfission/cas for my application. I have followed all installation steps. I am using windows, if that matters. More precisely, I have configured the following:
I ran the following in my terminal
composer require "subfission/cas" "dev-master"
I configured my Kernel.php accordingly, adding the following:
'cas.auth' => 'Subfission\Cas\Middleware\CASAuth',
'cas.guest' => 'Subfission\Cas\Middleware\RedirectCASAuthenticated',
I ran the following command:
php artisan vendor:publish
I also set up my cas server in my cas.php config file:
'cas_hostname' => env('CAS_HOSTNAME', 'cas.myserver.me'),
'cas_real_hosts' => env('CAS_REAL_HOSTS', 'cas.myserver.me'),
What I want is a middleware for all my routes, so I added the following route rule in my routes:
Route::middleware(['cas.auth'])->group(function ()
{
Route::get('/', function ()
{
return view('welcome');
});
});
Basically, I want to redirect everyone who is not logged in to the login page whenever I access the main page (for now, I will add more routes in the future). What happens is that the users are redirected to the login page when they are not logged in, but after the login I receive the following error:
ErrorException (E_WARNING)
DOMDocument::loadXML(): Opening and ending tag mismatch: hr line 1 and body in Entity, line: 1
No matter what view I'm redirecting the user to. I tried the default welcome page as well as an empty view, but I still get the same error.
EDIT: I have used the dev-master branch from subfission/cas for the above error and after switching to 2.1.1, I get a different error:
session_name(): Cannot change session name when headers already sent
EDIT 2: I did some more digging and I enabled internal errors in my cas client class with:
libxml_use_internal_errors(true);
And now I get the following:
Authentication failure: SA not validated Reason: bad response from the CAS server
And the cas response is:
The thing is that I use the same cas server for another 2 projects and it works well for those (but those aren't laravel projects.
I know it's been a while, but for anyone else having issues like this, the issue is the protocol selected for which your web service communicates with your CAS(Central Authentication Service) provider. There are two main protocols used for SSO/CAS in this package:
SAML(Security Assertion Markup Language) version 1.1 & 2
CAS Protocol v3.0
[Confusingly enough, CAS protocol shares the same namespace as the service.]
The idea is to match the protocol and version with your identity provider. It sounds like your provider is using CASv3.0, which is why disabling SAML worked.
Also, if you enable debug mode, you will see further error details in your log file to help your troubleshoot.
Best of luck!
I managed to solve the issue by disabling the SAML in the cas configure file:
'cas_enable_saml' => env('CAS_ENABLE_SAML', true),
change to
'cas_enable_saml' => env('CAS_ENABLE_SAML', false),

Phoenix: How to get conn %Plug.Conn{} in the console

After
iex -S mix phx.server
I want to do some quick tests in the iex terminal, but some functions require the struct %Plug.Conn{} as an argument, for example I wanted to get the result of expression:
MyAppWeb.Router.Helpers.confirmation_url(%Plug.Conn{}, :edit, "12345")
But I've got error:
Phoenix endpoint not found in %{}
Is there a simple way of getting conn struct in the console?
Router helper functions accept either a conn or an endpoint module as the first argument. You can pass the endpoint module of your app when you want to generate a URL without a conn:
MyAppWeb.Router.Helpers.confirmation_url(MyAppWeb.Endpoint, :edit, "12345")
Edit: If you want to create a dummy conn that works with Router helpers, it seems like it's enough to put a %{phoenix_endpoint: MyAppWeb.Endpoint} value in conn.private as of Phoenix 1.3:
conn = %Plug.Conn{private: %{phoenix_endpoint: MyAppWeb.Endpoint}}
MyAppWeb.Router.Helpers.confirmation_url(conn, :edit, "12345")
The ConnCase test helpers use Phoenix.ConnTest.build_conn() to bootstrap a connection struct for the controller tests.
You can find the function here and either use it directly or follow its implementation and tweak it as you like.
Why spending time with testing on the console. Just write a test and use the 'ConnCase' which gives you the conn struct in your tests for free. During development you can also use the "test watch" package which will rerun your tests on every file change.
As soon as you switch to tdd as more time you will save with problems like this

wev2py 1.99.2: saving sessions to database

In web2py version 1.99.2, at the beginning of default.py controller I wrote the following:
session.connect(request, response, db, masterapp=None)
I'm using sql server 2008 express edition. In db.py I have:
db = DAL('mssql://sa:mypass#.\SQLEXPRESS/mytest')
Now, sessions are created in the database as expected. Then in default.py controller I added:
#auth.requires_login()
def test():
return dict()
Also, default/test.html view was created. But, when I try to browse to the default/test.html page it redirects to the user/login page. The problem goes away, if I switch to the default file-based session. What's wrong with my code?
Try moving
session.connect(request, response, db, masterapp=None)
to db.py, right after you define the db connection. When auth is defined (I assume you have defined it in db.py or another model file), it needs to have access to the session, so you have to connect to the session first.

Zend framework - Where to Initialize session when the router needs access to it

I work in a project which uses the session a lot. We have a db handler (the standard one from Zend) and currently i have this initialization (db handler + session start) in a plugin for the preDispatchLoop. Previously it was in preDispatch but because of it being called for each action (included those in the 'forwarded' action, it caused me problems.
My problem is that i began working in internationalization and i began using the router to detect the language in the URI: we use the form /language/controller/action). The router would like to use the session to read/store the language. But as you may know the router comes first and then the (pre/post) dispatcher stuff.
So the question would be: why not move the session initialization to the bootstrapping ? it's because it was there before but i had to move it because i need to test that the db (remember that the session uses the db) is accessible to prevent errors. And if there's an error i simply redirect (request->setController/setAction error). If i move back the session initialization code to the bootstrapping i can't make the redirect if the db is not accessible.
I've read other question and i've found many people asking to access the request object from the bootstrapping. But they all say: you can but shouldn't. but then, how would i do in this case ? my last option would be to move back the sessions initialization to the bootstrapping and if it fails, manually send headers and read the view but the error code but that's a horrible hack.
My thoughts are that the session shouldn't be used that early. They shouldn't be called in the bootstrapping as they're not yet fully aware of the controller/action requested. I think that to get the language i could simply rely in cookies (manual) and get it from there (as well as from the URI). And if eventually some day the session info must be used in the bootstrapping i would use a global variable.
What do you think ? is there an error in the way i'm controlling the application ?
Some questions seen:
Zend Framework: Getting request object in bootstrap
Best way to deal with session handling in Zend Framework
(Zend version 1.9.6, not using Application nor Bootstrap)
I would move the session initialization and db connection to the bootstrapping.
If you can't connect to your db during bootstrapp this should count as low-level error. It is not excepted to happen in production.
Simply wrap your bootstrapping process into a try catch block so you can output an error page.
// in your index.php
try {
$application = new Zend_Application(
APPLICATION_ENV,
APPLICATION_PATH . '/configs/application.ini'
);
$application->bootstrap()
->run();
} catch (Exception $e) {
header('Content-type: text/html; charset=utf-8');
header('HTTP/1.1 503 Service Unavailable');
header("Retry-After: 3600");
// Output some error page.
echo "<html><head><title>System Error</title></head><body>...</bod></html>";
?>

Resources