I am really confused about when to use Mage::registry() and Mage session.
Can any one suggest what is diff between both on them and when to use.
The Magento registry is not persisted, as in once you are on a new page you will not see those registry variables still set. I mainly use the registry to communicate between controllers and blocks.
The session will persist, but know that there are multiple namespaces for sessions in Magento, and they will be cleared at certain times, like the checkout/session being cleared after the order is placed. It's best practice to create your own namespace for your session to avoid any conflicts like duplicate variables or clearing it at the wrong time.
As always Alan Storm has some good things to read on this topic:
http://alanstorm.com/magento_registry_singleton_tutorial
How to use Session in Magento
Use Mage::registry() when you want to access variable in the SAME page request (e.g. passing variable from controller to template)
Use session when you want to access variables across DIFFERENT page requests (e.g. navigating from one page to another)
Mage::registry() implies creation of new global variables which can be accessed anywhere within your Magento store.
Being a static function, Magento registry can be called directly without the object being instantiated as in case of dynamic functions.
Magento registry can be called like ClassName::StaticFunctionName().
while Mage::getSingleton() is just like session in PHP.
I hope I could explain my point.
Related
I observed that there are more than one session class in Magento, for example, Mage::getModel('core/session'), Mage::getModel('customer/session') and so on. When I want to use session as a storage, which session class should I choose? And Why? I'm just confused.
Magento's code is organized into modules. One of the purposes of a module is to provide namespaces. That is, modules allow one group of developers to write code without fear that their variables, objects, etc. will be accidentally stomped on by another group of developers.
Every module in Magento can have it's own session object. By giving each module it's own session object Magento helps developers avoid name conflicts in the PHP global session variable. For example, the following code
Mage::getModel('core/session')->setData('foo',$someValue);
Mage::getModel('customer/session')->setData('foo',$someOtherValue);
will save both values to the session, even though they have the same key.
As to which session class you should choose — if you're writing your own module you should create your own session class/model, thereby avoiding the above mentioned conflicts.
Practically speaking though, saving things on core/session shouldn't be a problem so long as you namespace your variables in some way.
Mage::getModel('core/session')->setData('my_namespace_foo',$someValue);
So I have a framework we've built on codeigniter. It uses regular codeigniter sessions by default which allows up to 4kb storage encrypted on a cookie.
Its for general apps that require a registration process, which can vary in size as questions are generated dynamically through an admin panel. Registration process relies on session data as it redirects throughout process.
I have used db_sessions in the past when I knew this would be an issue on the framework, however, I'm now considering the possibility to always have registration process using db_session and the rest of the site use the 4kb cookie session.
Is this possible. It seems like it could be a really bad idea, but I don't really want to rework the dynamic registration process or really use db_session for whole site as it will eventually make the site run very slow if too many users are online at once.
so I'm think I can just set the variable in config to be true only when the registration controller is loaded(by checking the url via $_SERVER or the uri helper if I can load it in the config which I'm guessing I cant).
Does this seem plausible?
It seems like it could be a really bad idea
You answered your own question :) You'll have issues when the user switches from one page to another. What happens if they open multiple windows, press a 'back' button etc. You'll need to switch the cookie over when they start registration, and switch it back at the end. It will be very very messy for basically no gain.
but I don't really want to rework the dynamic registration process or
really use db_session for whole site as it will eventually make the
site run very slow if too many users are online at once.
The reality is; your website has to be huge to have ANY real performance issues by using a DB for your sessions. Any if you are not using the DB, then you are relying on the cookie stored on the users computer. Depending on your site, this means they might have the ability to edit that cookie and change "admin = true" or something.
Just use the DB session - I think you are overcomplicating the situation.
I am having issues with using the session component in cakephp.
They worked fine throughout the site, when on a dev site on a different server.
After uploading the final version on the new server, it seems that the session will not start in certain controllers. Only on two controllers is this happening, but nothing seems to be done differently on these controllers - except possibly the fact that only these two controllers are using a custom file uploader component. Have tried disabling this and nothing changed.
The website is an ecommerce system, with the problems mainly occuring when trying to add an item to the basket, which is stored in a session. this session is remaining blank, whereas on the dev site worked a charm.
I am also using the auth component to login/logout, and although these 2 areas are not required to be logged in to function, they cause it to switch to logged out whenever they are loaded - and this then switches back by itself when any other areas of the site are accessed. The auth and session components are loaded in the appcontroller.
Thanks!
I've had a similar problem before now, and for me I was under the same impression as #starlocke that something needed kick starting. Instead of using Cake's Session component I used the session_start() command, after checking that $_SESSION was not defined. For example:
if(!isset($_SESSION)) session_start();
This was placed inside the beforeFilter() method of the AppController class.
I then also had a problem where it was saying it couldn't start the session because of there already being output to the server, this was solved for me by deleting any closing ?> tags inside controllers, as these aren't required by php and stop any unneeded output being sent to the browser like in this case.
Further reading on php closing tags:
Why I don’t use closing PHP tags
PHP closing tag
My personal experiences have shown that CakePHP's sessions are independent of Apache+PHP sessions. With that in mind, it helps to take some action to always guarantee that a CakePHP Session (instead of the usual Apache+PHP session) is instantiated early in your website's workflow , for example, adding something like $this->Session->read('foo'); inside your site's AppController's beforeFilter(). It shouldn't matter what key you try to read, and 'foo' should be enough to start your CakePHP sessions.
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.
Of course we can do this, but is it alright to do so? Are there any downsides of this approach?
What do you mean by session data? What programming language on the server (if you are referring to session data on the server)?
If you are using PHP, then you'll need to just call a PHP file with AJAX and delete using unset() (such as unset($_SESSION['user_id']) what ever you need to. I see this as just as risky as doing it with a normal request.
There's no reason you can't do this. The only concern would be that you'd need to handle any page state changes (like removing the 'account' links, etc).