I am syncing sessions between two different domains for Magento using a token passing technique with a remote iframe or img. I am about to implement it into Magento and was looking for some pointers.
I will have to do two things:
Every 5 mins, output an iframe or img with a remote SRC attribute for the second domain.
Q. Where is the best place to implement this? In the past I did storewide actions by overriding the renderLayout() method in Magento. Should I just do it by appended a block to the end of the page load? If I use a block, is it still keeping MVC?
I need to sync the session on the other domain when the script is called. I need to set the same cookie that Magento would set, that links to that session for the user.
Thinking about this, I think I am going to have to load Mage::app or whatever the call is that loads the Magento environment.
Q. Is there a lighter way of doing this?
Just for better understanding of what I am doing, here is a quick description of the flow.
User goes to Site A. If its time to sync the sessions, an IMG or IFRAME is outputted with SRC pointing to site-b.com/sessionSyncer?token=SHA1TOKEN
sessinSyncer validates the token and if so, creates a session and sends the cookie to the browser for the session. This should happen in a Magento manner
I am aware that Magento has the ability to pass session through the URL and generates the links to do so, but this is inadequate because the user must only switch sites using those special urls, plus the URL becomes ugly.
Thanks in advance!
Overriding renderLayout is overkill. Instead create a block that outputs your img tag and include it in the base theme, perhaps for the area before_body_end, that will safely place it on all pages.
Inventing your own token is also overkill since Magento is using the PHP session identifier and places it automatically for foreign domains. Your custom block might generate the URL with this:
$this->getUrl('OTHER/STORE/PATH', array('_store' => 'YOUR_STORE_CODE'))
If you think your script is going to need Mage::app() then you might as well use a controller which is a similar effort. On encountering a SID value the session will be updated behind the scenes, cookies set etc.
It using an iframe it doesn't need to output anything and if a small image can be static like this:
print "GIF89a\1\0\1\0\x80\0\0\xff\xff\xff\xff\xff\xff!\xf9\4\1\n\0\1\0,\0\0\0\0\1\0\1\0\0\2\2L\1\0;";
P.S.
When creating the URL of the foreign store without an SID use the _nosid parameter to force a clean URL.
Store sessions in DB and replicate database tables or entire databases it's much easier. You can configure that in your local.xml
<session_save><![CDATA[db]]></session_save>
Related
I have a PHP application custom_appli in /var/www/httpdocs.
Wordpress is installed on the same server in /var/www/httpdocs/new_cms/wordpress.
I need to retrieve user->ID using SESSION of custom_appli.
I have tried to insert :
require( './new_cms/wp-snapshots/wp-blog-header.php' );
global $user;
$user = wp_get_current_user();
echo "ID :".$user->ID;
writing wp-load instead of wp-blog-header doesn't change anything no matter whether I use include or require_once.
Could you please give me a link or advice on how to obtain user from SESSION?
Thanks in advance
Details and info are sparse, but here's how I would do it (I know about 5 methods, these are the least painful):
As mentioned, wp_get_current_user() gets you close, but that is generally only usable on the page for the user as in "on load" only. So from the WP served page you can get user ID (and all other info) and the session and have something that is usable. There are many ways to use that data to solve your problem, not really smooth all the time. Session data is etherial, beware.
Another way to go about it is to use wp-load.php and wrap it in middleware. this script bootstraps WP and allows queries and similar in the "bootstrapped" wordpress environment providing the applications internal API. I would consider adding wp-load to custom_appli "in the right way" and use that as middleware between the 2 applications. You will still need to identify the user as in many cases.
Without more information it is hard to guide you, but I can tell by your needs and the code already in the post that you are setting up for possible problems with dependencies, possible name-spacing collisions($user is something that could bite you as a global), and a myriad of other ways to loose time. If custom_appli needs a user ID, send it the user from WP on page load or similar.
When/why do you need that info? What is the flow?
You can also traverse a lot via session ID info too (depending on configuration).
FWIW I have passed user information successfully from 2 freestanding applications on different servers, it was very hard to do correctly, but it is possible.
Update after clarification
As mentioned "wordpress-user and cusstom-appli have same users" is possibly a replication of functionality, specifically running 2 tables(?) or logic. Just some feedback.
Basically you are wanting to hook the "logged in" status of a WP user. I see no mention of:
FK/relationships built on user (easy but a little more work)
ACL/permission based access on custom appl
No serializing of data or similar to the WP user (user in general)
Any of the above might have me change the solution. Here is a pretty clean prototype I wrote for you that is about 15 lines of code.
It follows some code from wp and essentially:
Makes sure PHP session is initialized via the theme functions.php
Uses the WP login (authentication) success to add a var to the session
On logout unsets the var (!IMPORTANT!)
Also makes sure the session is set when not logged in or the key is not present
Is easy to pick up outside of WP via session (custom_appl.php)
I tested this and it worked fine locally on one of my installs, I don't see any reason why it would give you problems. I would harden this a little more, but this is only a prototype showing how to use the key tools in PHP and WP.
wp_get_current_user() is a function in wp-includes/pluggable.php, which is loaded by wp-settings.php. I'm not sure how exactly WordPress bootstraps itself but I'd try to include wp-settings.php if anything.
Using the jQuery load function, i made it to where only the body of the website loads/changes. My header stays the same.
Rather than accessing your database, say, 50 times and requesting the same information on different pages, could I just risk a longer original loading time and include a php file that has everything i need stored in session variables for a user's account?
Are there any big security concerns for this or just any reason I am not seeing why this would be a bad idea?
I am finding myself accessing the same variables over and over again (like a unique id) on various php pages.
Sounds ok to me.
Consider if you need to synchronize and update the domain model (user account data) during access and want to resynch it to your client (view). What you describe however is common session behavior.
It sounds like you are doing it very low level, so you can go for this, without using a repository layer or dao or alike. Just read the date you need, be aware of concurrent access and ok.
For read only it is perfectly fine way of caching it.
It is a good idea imho. What else would you do besides a session, preferably via https.
Consider the security guidelines made here:
PHP Session Security
Yes, it is a bad idea:
Can a user alter the value of $_SESSION in PHP?
http://c2.com/cgi/wiki?GlobalVariablesAreBad
This might be a bit hard for me to explain, but I will try anyway.
In my PHP application, I have a main navigation which leads to different "Trackers", where I add a parameter "?trk=1" to the end of the URL for example.
I have a secondary navigation which I need to be different for the different "Trackers" in the system. From the main tracker page, I can easily get the id of the "trk" parameter, and create the secondary navigation based on that. But, my app has many sub-pages below the "Tracker" level. For example, every Tracker has Programs, where the Programs have Projects, etc.
One of the solutions I was considering was passing the "trk" parameter through all my pages. This way, my tracker.header.php file (which is run in all levels below the Tracker level in my app) could correctly generate a custom secondary navigation for each Tracker.
I was sorta thinking I could make a class for my secondary menu. I would create this menu object in tracker.header.php and I would then have access to this object variable throughout all lower levels which would then be very easy to customize per tracker.
Is it standard to hold all HTML generated in PHP in variables and then just echo the variables in the very last lines of the application?
Yes, it is fairly standard to have a single entry page (index.php) and all pages called are merely index.php with parameters either via GET or POST. Many people also use apache rewrites to hide the fact that they are doing this.
In your example, you might have a URL such as this: "./index.php?trk=1&prog=23&proj=12" and you would have to decide what to do in the event that a particular parameter was not passed.
It is also common to hold page state information in a session.
I think there's two questions in your post, but I'll do what I can to answer them:
If you need to pass along a category that's buried within other categories, there's a few ways to go about it, some easier than others. One such approach would be to append the chain of categories browsed in the URL itself. For example, ?trk=123&program=456&proj=789 could be reduced to ?trk=123|456|789 where the script splits trk every pipe character. If the end section is missing, you can assume it hasn't been set yet.
Also, it is common practice to output the page while it's being generated, usually with echo or by escaping the PHP tags for static HTML. If you're going to be sending a large page (such as one with a large amount of table data in the middle), then waiting until the page is fully generated may cause some browsers to assume the server has stopped responding. Also, in such situations it may be advisable to somehow make the giant midsection of the webpage asynchronous so users won't get impatient.
I'm currently working on an in-house CMS and have come to a bit of a standstill. I'm trying to make it easy to paginate between pages of posts in a blog, and can't decide on how it should be tackled. The real problem only arises when I need to allow a user to choose how many results to display per page or the order to sort posts in.
My initial thought was to simply use a querystring: blog/?page=3&count=20&sort=date but I'm not sure whether this method will have adverse effects on SEO.
For example, is Google sensible enough to realise that blog/?page=3&count=20 is the same as blog/?count=20&page=3?
I then thought about using sessions, but again this does not solve the problem above, and possibly makes it worse as some users may not have cookies enabled.
Lastly, I'm already using mod_rewrite for some of the urls, would it be best to use a structure like this: blog/1/20/?
I could really do with some help/suggestions here, there doesn't seem to be a hard-and-fast way of paginating results.
Thanks in advance
As long as those query strings are present on the links on your site (via static, normal 'paging' links which are spiderable) there shouldn't be any adverse effects. If your paging happens via sessions, however, that could have an impact, as that's usually done via cookies or by a long query-string propagated session ID. As far as I know, the order of parameters does not matter, as long as they yield the same output from the server.
The simple GET query string paging method works nicely. Google does it too (e.g.: q=test&start=10&...), the point is to make sure everything is reachable via plain-vanilla anchors.
Avoid using querystrings if you plan your site to get crawled satisfactorily.
Instead, use mod_rewrite and queries like this:
blog/page:3/count:20/sort:date
That will make it more readable, while keeping querystrings out of the way.
Of course, you'll have to parse that before doing the actual query, but it's something fairly simple to do in PHP: using explode() you separate each part of the URI, then parse from there.
Consider not having the order of the parameters fixed, instead allow them to be swapped and omitted, which will give you more flexibility when building the links.
I have always done this with session variables that get set via ajax calls.
I set an onClick event for each column header, and wrap the contents of the page in a div, so I can replace it.
I don't want Google downloading 10 different versions of the same page anyway.
On your comment about session variables:
I then thought about using sessions, but again this does not solve the problem above, and possibly makes it worse as some users may not have cookies enabled.
Session variables are stored on the server and not the client, so disabling cookies does not affect session variables.
Session variables are probably the easiest and most reliable way to solve this problem if you want to avoid google duplication issues.
I'm starting a experimental project and I was looking for advice to choose the best option I have.
The project will be on the 100 - 1,000 user count. It collects its main data using javascript + json data from the user's flickr page and then uses that to display specific flickr photos. The variables that need to be stored include user specific URL slug, and maybe 4 more short string variables. That all will need to be looked up on each page request. These variables will not change by time unless the user visits update page, and so these variables are static 99% of the time.
Each user's page will be located at /user-slug
I have thought out three options though I do not want to limit myself to these three (please offer your own), not being an experienced coder at higher access counts, I was looking for the fastest, most static & cacheable, least resource consuming way of achieving this, and I'm sure you guys are far more clever than I am at achieving this.
for the N amount users:
completely static approach: N static html pages are created, each user page is updated whenever asked, htaccess mod-rewrite is used to make each html file resemble a directory access. Updating; Php is used to rewrite the static pages when user asks them to be updated, or a full N user rewrite is performed when template needs updating. Most of the in-development code resides in a javascript file so the template itself will probably not be edited as frequently. Each time a user page is called, a static html file is displayed, javascript collects data from flickr server and displays it.
half static approach: Php + mod rewrite is used to simulate the different N user pages, user slug and only user slug is stored in MySQL database, then user specific variables are loaded via individual unique static texfiles named after the user slug (user-slug.txt) via javascript by the browser client (this data is not sensitive). Each time a page is called, 1 MySQL call is made and 1 extra txt file is loaded in the header via javascript. Javascript collects data from flickr and displays it.
full dynamic approach: Php + mod rewrite is used to simulate the different N pages (as the above method). All user specific variables are stored in MySQL. Each time a page is called, about 4 MySQL calls are made, Php creates the template page using those variables. Javascript collects data from flickr and displays it. In this method, which I believe is the more common approach to multi-user websites, I am also looking for ways to make these php/MySQL calls cacheable on the server itself. I'm on shared hosting btw, I don't have any low level access to the configuration itself.
Thank you so much for your input
Very, very appreciated!
I'd start with the full dynamic approach.
Then based on profiling and performance move those parts to caching that cost the most resources.
As they say 'premature optimization is the root of all evil'. Don't try to think what will take the most resources, but measure it by profiling time and memory usage.
I'd go with full dynamic as well. Though try your best to make whatever javascript/css you have static so it can be linked from an external file and not generated.