I want to create a shop builder that the user can create own theme and upload it to my host. and now I want to prevent users cant access database and model and resources in blade.
Because they can write malicious code through the blade on my server and cause system crashes.
I want to send only a list of variables for each blade's page that contains the values they need on this page and users can only use these variables and can not access my server database or resources and my files server.
I had to prevent user cant access database in the blade
Anyone have an idea for this؟
thank you
I have a need similar to yours
after several experiments and attempts I have found a solution that might work,
but with limitations/restrictions
it would be appropriate "from my point of view" to think about introducing another way to render your content.
in the face of my research I have found 2 possible solutions
introduce liquid
PRO
no type of access to the code
AGAINST
everything that will be accessible must be processed in advance
introduce TWIG
PRO
you do not have default access to eloquent or anything else that has not been passed to it
you can pass an 'object' intended as a php class with all its methods and properties
AGAINST
just because you can pass 'objects' you may come across the unpleasant condition that an object brings with it something that the view should not have access to
conclusions
in conclusion, 'my' choice was liquid, since it guaranteed me more security, in addition to other companies such as shopify have decided to use it also for this peculiarity
Related
I need to store some global variables for my laravel website, but I need to update them programmatically. Here is my situation:
the admin should be able to enable popups, and configure which post it has to link, which will show when a visitor comes to the website.
Other answers and why they did not satisfy me.
Making a laravel config file.
A database table.
Static variable somewhere in a controller or model.
A Laravel config file seemed to be the best option at first, but it didn't fit with the need to update them at running time. I've readt answers that suggested to call an artisan cache clear in the controller in order to update the values. but this seems just off to me. I don't think its a good idea to mess with the cache like that.
A database is still an option, however, it has some downsides as well. Making just an SQL table for 2 config variables seems like a waste of tables, it also means i need to make 2 query's on the admin dashboard, and also 1 on the homepage (to get the popup config), which i rather keep database-free.
A static variable in a model or controller. I saw this suggestion as well altough noted: it is probably a very bad design choice. Nevertheless i tried it in a desperate attempt and it didnt work. It did not stay updated on page reload.
I'm a laravel noob in case you didn't notice. Is there anything I am doing or understanding wrong? Or is there a solution I am not aware of?
There is no need for me to save the variable when the website is offline. It would be nice if it did but its only a minor inconvience for the admin to set it on restart.
For your situation, spatie write a nice package.
Just install as in documentation and use.
Use a db table to store the configuration, also having one extra table does not have any serious downside and it won't hurt the performance, also most popular applications/frameworks use it.
To reduce the db queries, create a wrapper class for your db config load, and in your wrapper cache the data for some amount of time, and when you want to change the config, remember to invalidate the cache.
If you want global access to it, bind it to laravel service provider, and use Facade or other container methods to fetch it. Also with this approach you keep the exposed config interface the same even if you change the implementation different in future.
About file solution: If you have one admin, you can go with file solution, but you never know how they will grow in numbers in future and it will be a hassle to go around what you did in file.
You can set config values dynamically at runtime with config() helper:
config([ 'app.popup1' => true ]);
Another solution is to write the config value into session at startup and only update the session:
session([ 'app.popup1' => true ]);
I'm new to CodeIgniter but want to perform best practices from the start. I have a simple authorization call that needs to be able to be called from several controllers. Hence I'm thinking it should be placed in either a library or a helper function. The call would take the user's id and a required authorization "level", grab their information from the DB, make sure they have that level of access, and return true or false.
Let's say:
auth($user,5)
My first instinct is to make this a library, but it seems odd to place it directly in a library because there are DB calls, which I would think should go in a model. It appears that only the Session library contains calls directly to the DB (for when database session storing is turned on).
So, I could access the DB directly within the library, or try to link to an external Model. Looking it up on the web, I'm only finding people who have trouble with both routes. Before I dive too deeply into getting one of them to work, I'd appreciate any opinions out there on how to go about this.
Thanks,
Jeremy
It seems like that is a model function. At least put it there until later in development.
If you later find there is a need for multiple models which would require duplicating the function, then would be a good time to move it to a helper or library.
I will be working on project that has different theme for each domain (same application will be serving multiple domains).
I need to change location of templates completely outside the application folder, possible on another volume
I need to make it work with multiple domains with multiple themes - i guess theres cache problem
S how to do this stuff with Symfony2 and twig?
EDIT: I will try to ask this: What or where do I need to rewrite to get custom logic on locating specific templates that symfony uses to render pages.
I can't say if first point of your question is a bad practice (and don't know even if it possible, but I would say yes).
However, what I would do is some kind of "manager" that will takes responsibility for choosing what kind of template render, based onto your own logic. Some kind of "intermediate level" between actions and views.
You could create it as a service and use everywhere, without have need to instantiate it every time.
It could read a file for configuration or, even (but less springy), use a class-internal configuration.
Algorithm could be something like this:
Take into account your request
"Eat" data and "spit out" the correct template (name)
Pass template (name) to your view
Extend (dinamically) the template given by your manager
Please, don't ask me some code because it could result in some hundred lines :)
Hey guys was hoping you could help me out.
basically i'm working on a website created using codeigniter by someone else. The site has two instances, one for development and one for live. The site is still under construction which means files are constantly being changed and moved from the development site (after being tested) to the live site.
Now the thing is, the person who initially created the site made some database calls from a few views. And to access the database from the view, he manually connected to the database from the view, i.e using
$db=mysql_connect(...);
mysql_select_db(...);
This means that each time a view is changed, before copying the files from the dev site to the live site, we need to change the variables inside these views.
moving all queries to models, and then calling them through controllers would take too long, so was wondering if there was a way through which i could access the database variables in the database.php file and pass them as the variable for mysql_connect.
i tried $this->db->database but get the error "Undefined property: CI_Loader::$db"
thanks in advance
There is no way to access database object from view. And you should also not do
$db=mysql_connect(...);
mysql_select_db(...);
in view. Try to remove those calls from view. And call it from model.
That is what MVC in codeigniter used for. Othervise what is use of using codeigniter framework.
See also:
access model from view in codeigniter?
CodeIgniter - Calling a function from inside a view
Define constants in constant.php assign them database username , password , host name etc and use them anywhere you want
First of all don't be eager about moving database calls to views, than take a look at this answer: https://stackoverflow.com/a/5835321/1444604
If this site is under construction yet, it shall be much better fix all this programing issues now than later.
Remembering that mysql_* codes are deprecated and won´t go much longer be accepted by hosts.
A hint that you could use what sometimes we forget, are those options of replacing texts presents in som many text editors and IDE´s, normally with a shortcut ctrl + H, you can rewrite a lot of code in many files, but be careful, or this can get all worse.
Well... said that, what you´ve tried to do in the view $this->db->database() maybe can work if you use this code before load database. I think it should
work just like as when creating libraries.
$CI =& get_instance();
Give a look on, but even if it works, avoid it as much as you can:
https://www.codeigniter.com/user_guide/general/creating_libraries.html
Good Luck!
I'm learning the OO and MVC paradigm (using Codeigniter and PHP). I continue to find warnings such as this: If you find yourself pasting the same code into multiple files, then you aren't using OO/MVC properly. So, here's a question for more experienced programmers.
I have a create-user form that I am using two very similar versions of:
Version 1 (at /volunteer/register) is created by an anonymous user. The form lives in the volunteers controller, and needs to be verified by an admin.
Version 2 (at /admin/create_volunteer) is created by a logged-in admin. The form and validation is nearly the same, but it is submitted with different parameters.
Another, similar example:
I want to build different user dashboards that share a template, but will be used by different user roles and have different functions and information based on role. As I see it my choices are:
Create a Dashboard controller with three functions defining the data loaded into the dashboard template.
Add the a dashboard function to each role's controller (Volunteer, Admin etc).
Create a controller for each case (Volunteer, Admin, etc.)
I apologize if this appears sophomoric but essentially I'm looking for rules-of-thumb to determine how to design architecture in MVC.
My questions:
In the first example, is my logical choice of controllers (Volunteer & Admin) less than ideal? Is code replication in this case an acceptable practice?
Can anyone recommend architecting tools to establish logical consistency and good workflow for MVC?
Especially since the two forms are not the same (different rules, different interface) there's absolutely nothing wrong having two separate view files if you need it. Loading the same view file in two different controllers or methods is perfectly acceptable, indeed it's appropriate. If there are only a few tweaks that need to be made, try to reuse the view file by passing different data to it.
If you want to simply load the form view file in different instances, that would save you some code duplication. Just set different rules and if needed, pass different data to the view. It's similar to using the same form to create and edit something in two different methods. If the output is going to be totally different, just write separate view files. If it's the same output but with different data - definitely reuse it.
Don't get obsessed with trying to not duplicate view fragment code - if you are writing even more code to force the reuse of a view file by modifying it for different instances, it kind of defeats the purpose. Try to just make it a general practice to make your code as reusable as possible.
So, without seeing your actual code - I'd say don't worry about it. In my experience, view files for front-end and back-end are almost always unique (completely different UI). In general, if you find you are duplicating the same very similar code a lot, it's time to write a function, class, or template for it.
It seems you would like to use some ACL for distinction between roles (Volunteer and Admin) that will check whether requested module or action can be accessed.
Creating different controllers for the roles doesn't seem to be a good choice since this architecture could not be reused - you don't want to reuse specific Admin or Volunteer functions in other applications but rather a module that lets you create and control such roles.
You would like to reuse a code offering particular functionality, this might be one controller, one model and some view files.
Most programmers consider duplicated code as a sign that the solution to a problem still can be improved.
If the problem in your case is that the from is defined in one controller but you need to use it in another controller as well, then you need a better place to define the form so that both controllers have access to it independently from each other.
Make the form configurable so it's possible to reuse it.