Is there any way I can make user URLs? something like
www.domain.com/username
I know I probably have to use a route system, and I do use this a lot for other URL requests. But the thing is, I need the username to dynamically create the user profile, if it exists. But do I also need to keep my other controller classes in mind?
Thanks!
I see you realize the potential for a user to step all over your other valid routes by creating a matching user name.
You could try routing all requests as usernames, but providing a trigger for your other controllers (and other valid routes):
// Route everything to users profile
$route['(:any)'] = 'users/profile/$1';
// Route all requests after "my_trigger" as normal
$route['my_trigger/(:any)'] = '$1';
* I'm not sure, but you may need to append more /(:any)s to the trigger routes.
This would mean that my_trigger would have to be an invalid username, but would be the only invalid user name.
The idea is that all non-username requests must be preceded with the additional "trigger" segment, otherwise it will be considered a user name. So /blog now must be accessed with /trigger/blog.
You could of course do the same with the user name instead, but end up with a less pretty url, like /u/username, or use a query string like ?u=username.
Another option is to specifically whitelist segments that should invoke a controller as normal, and blacklist them from the available user names, while routing all other requests through your users controller.
In any case, if the user name doesn't actually exist - you need to respond appropriately, so there is no real need for "dynamic" routes (i.e. creating a route for each and every user).
Related
We are developing an application in Laravel 5 where users can login and based on the licenses assigned to the user, multiple "content types" are available within the app. The business logic and presentation logic differs based on the selected content type. The user can select the content type to work with, or, if only one license is available, will be directed to the homepage of that content type.
Now I am trying to figure out how to handle the selected content type. Storing this in a session is imo not the way to go because a user must be able to use multiple content types in one browser session simultaneously.
I figured I need to start with grouping all relevant routes and prefixes them with {contentType}. Also, add a Middleware (named something like SelectContentTypeMiddleware) and let that middleware check if the content type exists, and if the logged in user is allowed to have access to it.
Furthermore, every descending route (in the {contentType} prefix route group) also must handle the route parameter $contentType.
I am trying to figure out of this is the right approach. I was looking at this blogpost which addresses the case for setting the app locale. Using app()->setLocale($locale) the locale for that request is set. I was wondering if a similar approach for my case makes sense, or that including the route parameter $contentType in every route is more advisable.
I have a website that serves up various information for users who have accounts on it by accessing information listed under a username and a category. Using the variable names, u and c, the url looks like this:
www.originalwebsite.com/user.php?u=username&c=43
I want a user-defined custom domain to remove any evidence of a username variable or variable name. Other variables (like category) are fine to remain. Ideally, this would result in the following link pointing to the one included before:
www.customdomain.com/c=43
My reasons being that the custom domain would be unique for the user and, therefore, would be remove the need to specify the user (in theory, not in practice so far) as well as presenting the site from a custom domain in a manner that looks like a single site, rather than the portal like options of the original.
I can get www.customdomain.com/u=username&c=43 to work but am trying to think of the best method to remove reference to the username when using the custom domain (both the variable identifier and the variable itself). I'm struggling to think of how I'll inform the original website of what user account to use if it's not mentioned in the url itself.
At the moment my best idea is to let user.php handle this with a condition of whether the request is from originalwebsite.com or a custom domain. If finds that it's the latter, it checks it against a database listing and finds the relevant user settings discreetly. This feels like quite a slow procedure, however.
If my example is not clear, think of sites like Tumblr, where you can add a custom domain and, from that point on, urls make no reference of your user name.
From some discussion here and further research, it seems as though there's no quickfire way of doing this. It looks like I'm stuck with either keeping some form of reference that can identify a username in the url, using a cookie or sticking with my original idea of referencing the custom domain against a database to find the appropriate user and settings.
I've gone with the database referencing option as I need to remove references to any username from the url and I can't always rely on cookies. I need a 100% success rate of correct redirection.
I've changed my user.php file to check if the request has come from originaldomain.com or newdomain.com. If it's from originaldomain.com, it looks for a username variable in the url as it should have one for any user that doesn't have a custom domain. If it comes from a different domain, it checks to see if this domain is listed in the database and finds the user from this. There's a few catches that I'll need to trial but I've got 90% of the issue solved.
I have an application on which I would like to display two different contents based on a certain app_id when the user is connected. I don't want the app_id to be shown to the user (so he won't be able to modify it). Therefore I don't wanna send it as a queryString. The application main file is index.php. So, when the user access index.php I want to adjust the content according to the app_id. Any idea how I can pass that app_id to index.php, without showing it to the user?
I was thinking about $_SESSION but because there is only one index.php file, I can't really do something like this:
if($_SESSION['app_id'] == 1)
{
// call index.php file of app 1
}
else
{
// call index.php file of app 2
}
I don't want to duplicate the content. I want to keep everything in the same file and use conditions to display the correct elements based on the app_id.
Thanks for any help
Because http is stateless and passing the app_id in query string is not a option for you I suggest the next concept.
Store the app_id in a session or a cookie; If you mind that a user may not modify the app_id I suggest session over cookie. Because a value of cookie can be modified by the user so then you end up with the same issue.
Store the app_id into a session and load the app_id value into factory method pattern;
Check for further explanations of the design pattern "fatcory method" over here; http://sourcemaking.com/design_patterns/factory_method.
Basically the design pattern is responsible to create the desire "app_id" instance. By that you can organise your code much better plus if you have a new "app_id" just define a new app class and define it into the factory method class.
By that it also doesn't infect your entire codebase because your encapsulate the creation of your app instance and you can easily using the instance in your entire code base (of course if that is needed)
I hope this helps for you
I am developing an application in php codeigniter. Now I am worrried abt the permission.
I need page wise permission, page may be add records page, edit page, delete page and print report etc. There will be many users as well, and applicaiton will grow with passage of time.
If I implement ACL that will better for me or not
what can be ideal for me any suggestion.
First, let's clear up some terms: I personally use the security term for things like preventing SQL injection, XSS attacks, where we have to validate input, filter/sanitize values, take care of the dynamically generated SQL commands, take care of properly escaping output (for JSON or HTML text or HTML attributes), etc. This is not about what you are asking, if I understood well.
The access control or permissions system is where you give or deny access to a function for a user. It can be secure or not. I understand that to deny a user which does not have permission the access to a function may sound like "security", but I wouldn't use this specific word in this context, to avoid confusion.
Now, the answer:
I strongly recommend you create a few base controller classes to your needs. Read the following blog post carefully (it is short and useful): http://philsturgeon.co.uk/blog/2010/02/CodeIgniter-base-Classes-Keeping-it-DRY
A code to check if the user is properly authenticated (logged in) is essential. If the user is not logged in, redirect to home page or login page.
For fine-grained control, you could create your ACL in the database using the users table, plus an actions table, plus an acl table...
The users table would contain the users data (id, name, login, password, etc)
The actions table would contain the id field and at least one more field containing what suits best for your application: it can be only the controller class name (the first part of the URL, for example: "products"), granting access to the whole "products" controller or not. Or you may want to include both the controller class AND the method name (the first and second parts of the URL, for example: "products/add" and "products/delete"), and so on.
To decide about the actions table is the most decisive step. Think very well about it, balance your needs (your "true" needs)... I developed a system where each and every action has its entry. It is good, but it needs work to be maintained.
A very useful column for the actions table is a human-readable description of the action.
The acl then would be nothing more than a column for the user id and another column for the action id.
A "master" grant/deny access field in the users table is useful too, in case you want to temporarily deny access from a specific user, without having to delete all his permissions and maybe having to restore it later.
With the database tables and your "controller/method" or "actions" strategy well defined, you can easily code in your base controller class a function which checks if the user have permission to execute the requested action.
This is the basic. In my system, I have the users administration interface, where I can grant/deny the actions for each user (I use an ExtJS tree with checkboxes). One of these actions is the own user management. I have gone one step further, where the user who can access the user management may "delegate" (grant/deny) to other users only the actions he himself has access to.
The system has several modules, and functions. The interface does not show anything the user does not have access. So, I have users who can see only a single or a couple of modules, and they don't even imagine the existence of the other modules.
It requires more work to manage all this, but the result worths.
I also log each granted access, so it is possible to track who did what, and when. This log feature is very very easy to add, since you have this base controller "master function" allowing or disallowing the users to perform the actions.
I hope I have helped. I've just shared a bit of what worked (and works) for me...
Busy building my first web application in CodeIgniter and wanted to work out the best way of gathering ID in my Admin function for Edit, Delete statements.
I realised I can use any of the following:
Pass the ID through the controller.
Collect the ID from the URI segment.
Collect the ID from a hidden form field.
Which is the best based on security concerns. i.e. People fiddling with the URL, etc.
I prefer to use the URL for unique IDs, that way you get nice-looking URLs that people can bookmark. You shouldn't rely on how you pass the data for security, you should be doing input validation within your controller regardless of how you pass it.
If this is for an admin section, it should may no difference. Unless a user is authorized to view the output of say, the Admin Controller, they should see "page does not exist" for each one of those methods.
Collect the ID from the URI segment. is my choise..nice url!