I'm using Laravel 5.2.29 and I've set up some scheduled commands.
One of them uses some methods used in my app through normal use (i.e., via a browser) and so the session is accessible.
However, when I try and run the command manually using artisan schedule:run, I get the following exception:
Session store not set on request.
The Session isn't being set (I suppose in the same vein as if a route were accessed without the web middleware), so is there a way to manually boot up the Session? I'd rather not rewrite my methods to not use it.
You don't have access to the session in CLI. Session is strictly connected with the web browser (client side) which doesn't make sense in command line.
If You need a local storage (for server side) You can try with cache driver.
Related
So im building app based on Express and using Prisma ORM. What i need is to SSH to a server, open up express.js console and create new db entry using prisma. Something similar to python manage.py shell for Django or rails console for Rails. Is there a solution for this of any kind?
Like I pointed in the comment there is a way ( kind of ) to get access to a running express instance. If that's all you need follow:
How can I open a console to interact with Express app?
Express doesn't exactly have a feature like rails console which is a framework feature in that case.
That said, I question the long term implication of this approach. If you really just need to seed some data, write an "init" script, and call it after you ssh into a server or using some CI/CD approach. This is more re-usable, since you can even pass a json file to the script to load dynamic data.
Also, Prismajs has an official way to seed the data ( if that's what you need) that you can leverage:
https://www.prisma.io/docs/guides/database/seed-database
UPDATE:
If you are able to run to code on your machine and point the remote database, then you can use node --inspect to debug in a chrome console. Which should give you about the same effect as a rails REPL
https://medium.com/#tbernardes/debugging-nodejs-with-chrome-inspector-devtools-1cd2ef323b5e
We have a windows application which is written by electron and SQLite as database, the problem is we want our application to secure the database file after its first authentication with database, and only have the application itself can modify the file, while preventing the windows standard user from modifying or deleting the file manually. What are the options here?
You can use third-party applications like https://robotronic.de/runasspcen.html
Run application as another user or start program as administrator from a limited account like the command runas, but without to enter login information on each start.
I want to use dynamic databases on runtime without effecting config/database.php because of concurrent users.
I have a main db with a table that contains reference to several other dbs. Now at runtime I need to not only connect to those dbs but also may want to run migrations on them.
I am aware that this is possible by having a second connection entry in config.database.connections but I have a feeling that if two users hit the server at the same time, the physical config file changes may create a conflict.
I also read (and also experimented) that you can edit the second connection using below code at runtime:
\Config::set('database.connections.mysql2.database', 'somedynamicdb');
DB::purge('mysql2');
But I fear that if it persists changes for different users, then it may conflict for concurrent users. And if it does not persist changes, then it wont work for migrations.
I want to understand/know two things specifically:
What is the scope of this above code (i.e. Config::set() call)? Does it persist over different user calls to the server?
If I call migrations using Artisan::call('migrate') with a --database=connectionname clause, right after I change the db name in connectionname, will that use the dynamically set database or the physical config value?
UPDATE
Also worth noting that a call to Artisan::call('migrate') with a --database=connectionname, will make the new connection persist for the rest of your app call.
See here for details:
https://github.com/laravel/framework/issues/28253
Config::set will only apply for the request for which it was set, won't apply to any other requests, and will not persist beyond the request. If you're not processing a request (e.g. a CLI command) then it won't affect anything beyond the current PHP process.
As for Item #2, if you're invoking from the command line, you can just do DB_CONNECTION=connectionname php artisan migrate. If you need to invoke the artisan command from code, using Config::set is still the right way to go.
We use connection created on the fly here all time and works very well. We setup this on Middleware that we included after authentication and is only valid on the user current user request based on login information.
I connect to a remote sqlserver database using the jdbc service. My apps script has my password and userid. Is there a security risk involved. I ask because javascript is open to inspection; are app-scripts open to users?
What is the best way to get that secure information into an app?
Even hard coded values don't show up in the javascript when rendered by the browser. That is because all the code that you write runs on the server side (except client handlers).
However, if you share a script or spreadsheet with the script with another user, the code is visible to the other user.
You can store your username and password in a spreadsheet that only you have access to and read from there during runtime. However, ensure that the script runs under your id (i.e only published as a web app).
Use the UserProperties service. It's values are only available to you and if you decide to make the application multi-user, you could even direct users to store their unique sql username/password in their own UserProperties.
From a Windows Service running on a Terminal Server (in global space), we would like to be able to start up a process running a windows application in a specific user's Terminal Server sessions.
How does one go about doing this?
The Scenerio: the windows service starts at boot time. After the user has logged into a Terminal Server user session, based on some criteria known only to the windows service, the windows service wants to start a process in the user's session running a windows application.
An example: We would like to display a 'Shutdown in 5 minutes' warning to the users. The windows service would detect this condition, and start up a process in each user session that starts the windows app that displays the warning. And, yes, I know there are other ways of displaying a warning dialog, this is the example, what we want to do is much more invasive.
You can use CreateProcessAsUser to do this - but it requires a bit of effort. I believe the following steps are the basic required procedure:
Get the user's session (WTSQuerySessionInformation).
Get a token for that user (WTSQueryUserToken).
Create a duplicate token for your use (DuplicateTokenEx).
Use the token to create an environment block (CreateEnvironmentBlock).
Launch the application with CreateProcessAsUser, using the block above.
You'll also want to make sure to clean up all of the appropriate handles, tokens, etc., after you've launched the process.
Really late reply but maybe somebody will find this helpful.
You can use PsExec to launch an application on a remote (or local) server inside a specified session by using the following command:
psexec \\COMPUTER_NAME -i SESSION_ID APPLICATION_NAME
Where SESSION_ID indicates the session id in which to launch the application.
You will need to know what sessions are active on the server and which session id maps to which user login. The following thread provides a nice code sample for this exact problem: How do you retrieve a list of logged-in/connected users in .NET?
Late reply but in the answer above DuplicateToken is not necessary since WTSQueryUserToken already returns a primary token.