I'm working with a Joomla site, whose index.php file has been modified to alter the default access control behaviour. Bearing in mind this is Joomla 1.5, this line:
$mainframe->authorize($Itemid);
has been wrapped in some conditional code that looks up the remote IP and doesn't call authorize() if the IP is within a whitelisted range [*]. This is to allow seamless access to certain resources without logging in.
Although I'm new to Joomla development, I'm guessing this isn't the best way of doing that. For one, it probably means re-patching index.php in the event of a future Joomla upgrade. What's the best alternative approach to intercepting the authentication check?
[*] This is another mystery: the IP management takes place on the front-end via a component called 'IP filters'. There's a totally empty directory at components/com_ipfilter, but a more featureful-looking one at administrator/components/com_ipfilter. The component stores data in a table named kip_filters (why the 'k'?) and the authorUrl listed in the component's manifest file goes to a spammy-looking like pharma page. All quite worrying ...
What you are looking for is a system plugin which would not require hacking any files. There are quite a few system events that you can use to trigger your plugin and do your IP test, then determine whether to continue displaying the page or redirecting the visitor to some sort of warning page.
Take a look at the documentation on system events - http://docs.joomla.org/Plugin/Events/System
--- More detail ---
Looking at the API execution order, the call to authorize() is going to happen no matter what (http://docs.joomla.org/API_Execution_Order). Since the default behavior is to call authorize() you are going to have to trick it into returning a positive response.
Your plugin should be triggered by onAfterInitialise and you should manipulate JUser. When you call authorize() the functions needs a user id which it gets from the JUser object and the getuser() function. All you need to do is create a user with the permissions you want, then have the plugin set the user ID so that authorize() returns true.
For the security problems you can use these steps and i will give you a good ip filter component as well :
First of all this is the most important component you can have for joomla :
http://extensions.joomla.org/extensions/access-a-security/site-security/site-protection/16363
it gives you the most important ways to avoid any hacking or spamming or php bugs and also provide a very fast upgrade for your joomla site :) also it offering a IP Blacklisting manager which is a complete solution for your problem.
Hope this post will give someone a light !
Regards,
Raeed Rabie
I'd advise changing your table prefix from jos_ to something random, like hsfdaghadfg_
You can also relocate your configuration file for extra security.
Related
I'm having a bit of trouble understanding the proper times to use ACL or middleware in Laravel. I do understand the examples on their site and Laracasts, but they're rather simple examples.
This isn't anymore complicated by any means, but I didn't see examples for these. Let's say I have two routes that allow a user to create a task. The first being the GET request to fill out the information, and the second being the POST to store the information. There are some users that are not allowed to create tasks based on their role. In both cases, there isn't a particular object that exists, which is what the ACL requires as far as I understand. So would I use middleware for something like that? And when an object exists, use ACL for that?
An alternative I've been trying to fit in is the use of Form Requests too, but then I'd have to create a Form Request object for each route (although I don't really mind personally).
What is a good approach to limiting acccess to actions, when there isn't a specific action to act upon?
Thanks in advance.
Notice: I was going to post this as a comment, but it got a little too extent. Feel free to wait for better answers and maybe consider this just a comment.
I think that you're missing the whole point here. You can have a middleware that consults the ACL or you can use the FormRequest to consult the ACL or use each of them separately. For instance, at the authorize method of the CreateTaskRequest, you can check the ACL to see if the user has the proper role to create a task.
You might be getting too hooked up when Jeff tries to check if the user owns the post. That kind of ACL is record-oriented, but you can have a role that just takes the user as a parameter (and no other entity) and see if that user just has a specific role. By returning true, the action is authorized, otherwise it's denied.
A middleware have more to do with the route instead of the request. You can also have a middleware that gets the authenticated user and check if it has the role to create a task. Those are different ways to achieve the same thing (which is one of the benefits of Laravel, having lots of ways to achieve the same goal).
Your specific action to act upon is the "Create new Task" action. Who do you want to be able to do that? Users that have the role manager? Users that have the permission create-task?
At the end of the day, what I would consider is:
Are there lots of routes that will have the same rule? Maybe a middleware would be a good choice.
Are there specific rules for each kind of operation? Can an user that did not create a task be able to edit one? Form Requests might be easier to achieve this kind of specification
Which $this environment would make my life easier? $this from the Form Request or $this from a middleware?
One thing I learned from Jeff's class are that he teaches too much cool stuff and sometimes I end up missing one point or two. Try re-watching the basic steps again and maybe stop when you think you found something that would work. Then implement that and see what your case differs from his and how you think he'd write that feature.
I wrote a plugin for joomla that adds custom fields to the user/register component. There are 3 different registration forms for different user groups.
The plugin acts on onUserAfterSave() and works fine, but there is one problem. When there is an error in the original user component, for example: "the username has already been taken" the form is redirected and neither onUserAfterSave() or onUserBeforeSave() is ever called.
I want to change that redirection, but without changing the core, but since neither plugin events are called, im not sure how to. Can you guys help me? Maybe I am missing something!
Is it possible to maybe override the save() function?
THANKS
I had same problem many times, so i can share a solution i use myself. If you don't want to edit Joomla core files, you can do the following:
Create your own template override of registration view.
Duplicate the components/com_users/controllers/registration.php file and lets say name it registration2.php
In your registration form override change hidden input's "task" value from registration.register to registration2.register
Feel free to override registration2.php classes how you like.
It's totally Joomla update proof, so you can update your joomla version witht worrying about errors.
I think you might need to do the checks that joomla is doing in your plugin and redirect in your plugin itself in the case that it wont pass. I see your predicament and I don't know a better way but I would pick a different event to run it on maybe even after page load and then on UI event in javascript.
The only clean way to extend the user registration/profile is to create a profile plugin like this one
https://github.com/joomla/joomla-cms/blob/master/plugins/user/profile/profile.php
You can extend com_users forms in backend and frontend.
I want to use thisdomain.com for say a review site where each company has a set of sub pages... about, info, and related reviews.. and where we use the blog module to manage the review/posts.
Basically, I want the url structure to be as such,
thisdomain.com/[company]/[blog|pages|etc]
and also maintain core site pages for thisdomain.com,
thisdomain.com/[blog|pages|etc]
My first thought was to add an if statement to the system config/routes.php file and route all requests for thisdomain.com first to a module to db check if we have a company that fits otherwise send it back to the default pages controller. But I haven't gone far enough down the rabbit hole to know if this is a lame concept.
Has anyone done this? Ideas? Is this retarded? Phil?
I wouldn't have thought this was possible. The issue here is that even if you route it through then CodeIgniter will not continue to trickle down through the remaining routes, which means your one global company route would break every other route in the system.
You can just do this sub-pages and use the blog plugin to get a list of pages based on a certain tag or category. /foo/blog would just be a page, and you call up the "foo" tag. Then link to your own /foo/blog/article/slug where slug is used to call the blog plugin again.
The module output is generally there to give you a default interface, but you can ignore them if you like.
Hello I'm new to Joomla and I want to change the way an account is created (in Joomla 2.5):
Change the registation form (remove one or two fields)
Change the registration logic: I want to add more stuff in the sent email (and a pdf attachment) and also i want to call some other functions (or make extra requests), analyse the result and then return the response to the client.
What ways are there?
Had an earlier answer for an earlier version that didn't apply, but found this tutorial to get myself up to speed. it lists all the files, etc. that you need to make changes to, but doesn't mention your email requirement. To do that, you'll likely have to look at function register($temp) in components\com_users\models\registration.php
You can change the settings from the component directory of the template in the PHP file.
you can if you install SEBLOD, it's a content constructor that can modify article form, user registration form and much more.
It will help you with almost everything you need, but to call other functions or make other requests you will nedd to digg a little more into Joomla registration.php
i'm in the process of adding a US site to my current UK site. I'd like to do this as transaprently as possible so that we don't lose any traffic to existing links. We're currently running this under version 1.4.1.1 of Magento on a shared hosting setup.
The new website (US) will be essentially the same as the current (UK) site, but with US Dollar pricing instead of Pound Sterling.
We currently have a GeoIP setup whereby visitors are redirected to either UK or US site whilst utulising the same URL. This essentially means that we have switch statements in our index.php to indicate what run code to use.
Here's my question:
what's the best way of selecting/overriding the GeoIP selection via the standard store switcher selector dropbox? Both websites are being populated in the dropbox, however, since both are utilising the same URL (www.example.com/boutique) the default one is the only one that's being selected.
I've also tried the &_store= as well as the &_website= arguments with no success.
Any ideas? are URL rewrites in .htaccess the answer? if so, any ideas as what to use?
P.S. this is the method that's pretty much being followed however my aim is to let users override their location-specific website (e.g. US) if necessary:http://www.magentocommerce.com/wiki/4_-_themes_and_template_customization/navigation/multiple-website-setup#multiple_website_setup_for_useuuk_storespricing
Have you tried using a getUrl() method to build the store arguments for you? It can help clear up those little misunderstandings, for example I'm pretty sure the store parameter is supposed to have three underscores but cannot really remember so I use the function instead.
The best way to over-ride is to have a little php program, e.g. 'countries.php' that sets a cookie depending on the country code that you choose or 'auto' to test regular geoip. Then in your index.php have an 'if cookie then use cookie code else use geoip code'. Naturally the cookie can only be set by your test program.
And yes, you only need set 'website' not 'store'. There is no benefit in your US customers being able to see your UK prices (and vice-versa) so don't even bother with setting up a frontend drop-down. Or, if you really want, you can have rest-of-the-world customers choose their currency/website and put your own cookie-setting code in the header for them, with a couple of nice flag icons.