Basically, we have a site and a store already setup (not using WorldPay), but we’re changing to an entirely new website design, with a new store, using WorldPay this time (but using the same domain name as before).
Everything is all tested and ready on a temporary URL, so all that is left to do is have WorldPay activated and switch the domain over, but how can we give WorldPay access to test and activate our installation WITHOUT letting customers see the site at the same time (as we want to launch it on a set time/date).
The options from our perspective were:
WorldPay tell us the IP address they will be checking over the installation with, and we can limit access by IP address using htaccess or similar.
We change the URL temporarily to something like “/store38382882” which no one will know about, then once everything is activated, we would need to switch back to just “/store”. But from what I can see in the WorldPay docs, the URL you provide them with isn't easily changeable.
Are either of these possible? And if not, how is this usually handled? Just hoping for advice from people who've done this before!
I put site on a sub domain, in the worldpay admin area, you set the callback URL and passphase specific for the sub domain.
Once you are ready for live, you just need to make sure that your settings also match up with the live configuration of your account on worldpay
for example:
live callback http://www.site.com/worldpay/callback
Testing and demo http://test.site.com/worldpay/callback
You should have bindings in your code to detect the Host URL to pick up if its www. or test. this will enable you to have settings for live and test without having to do many changes to your code, or worse, having two versions of the code base.
hope this helps
Related
I've developed an application that a client might access at a URL like this: http://example.com. In this case, I own and control http://example.com.
I now have a case where another company would like present my application as their own by changing some of the branding and the URL (say: http://companyx.com). The application and all the data will still remain hosed with me just like it was at http://example.com.
What's the best way to handle this? I was going to create a separate directory for this company so I can update the branding (mainly just a logo) to make it specific to them, but I'm not sure how I can make this directory accessible to people going to a directory on the company site (http://companyx.com). Using sub-domains is also an option if this makes it easier. Assume that I'll be able to add records to companyx.com's DNS, etc.
You need to create a separate directory, then create a subdomain at sub.example.com and point it to directory (you can do this from your hosting control panel). Now your company needs to point their desired url (within their domain) to your subdomain.
IMHO this is the cleanest solution, if you need to have control over the site's content.
edit
what company needs to do is to point cname record of domain to your url and it should work, (otherwise you will need to get separate ip for your subdomain in order to point A record there)
I am developing an app using Phalcon and would like to create a popup logging window that displays any logging type information when I am logged in (such as DB calls and exceptions).
Alot of my app is driven by Ajax calls. Is it going to be possible to have a window that I can popup on my main app that uses a tail like method of displaying this information?
How would I go about this? I'm not entirely sure that what I want is possible with the Ajax calls as they are done in a different request. I can't find anything on the internet as to how I would go about this so any help would be great.
Well, you didn't said that explicitly, but I imagine that you want this just for development purposes. If so, you can log useful info to a method that checks if it should send that log to the browser based on some criteria (e.g. logged in user is you, the app is in a dev enviroment, etc) and then use Phalcon's FirePHP log adapter to send to log the information to the browser.
You'll just need to have some FirePHP extension in your Firefox or Chrome to be able to see the information under your JavaScript console. And yes, it works well with Ajax calls too.
Let me know if you need further explanations on this...
I think you are looking for a debug toolkit.. There are lot of toolkit available on packagist.org and phalconist.com. I personally like this phalcon-debug-widget toolkit that you may try.
I've registered a domain with www.domain101.com. We'll call it www.example.com. I used their 'cloaked forwarding' option on my heroku app, which we'll call example.herokuapp.com. If I want to navigate to the posts index page, I would go to example.herokuapp.com/posts, of course; however, when I try this with my cloaked domain - www.example.com/posts - it takes me to the landing page. What's more, the url is constantly set to 'www.example.com' and the title of each page is "EXAMPLE.COM". I can click buttons on the pages and navigate through my website, but the url remains strictly at 'www.example.com'.
I used the forwarding option available on the website. What else should I be doing?
Domain cloaking uses a frame to make visitors' browsers show the cloaking domain in the location bar, while having the actual content hosted somewhere else. That's why the location bar never changes when you navigate around the site; and it isn't surprising that domain101's cloaking implementation doesn't forward path information to your Heroku app.
What you should do instead is configure a DNS server to direct traffic for your domain directly to Heroku. The simplest option for that on Heroku is the Zerigo DNS Add-on, which is free if you're hosting a single domain. You can also find DNS servers provided by lots of other people if you prefer.
Once you've configured a DNS server, you also need to tell your registrar that the DNS server you chose is the primary DNS for your domain. The way to do that varies between registrars, so you should check domain101's documentation for details.
From my experiences so far, I've concluded that the HTML5 Manifest scheme was really terribly designed.
My site serves a manifest file when a user is logged in. Unfortunately, when they log out, they can still access the cached protected materials. Can anyone think of a way to fix this?
A manifest file is designed to take a website offline and still be able to navigate. It essentially just tells the browser to download and keep that stuff in cache. If your adding secret stuff to the manifest and the user goes offline, he needs to be able to still access it - or whats the point of having a special logged-in-manifest-file if he has to be loggedin (therefor online)?
You could add javascript that checks if the user is online again and if he is, tries to validate the "login state" and redirects or removes the secret stuff from localstorage (if you would use localstorage to save the "secret" stuff and javascript to display it instead of a manifest file )
Lets say the secret stuff is an image and you are not using a manifest file, but just displaying images when the user is logged in and its crusial, the user cant view that image after logout, you would need to set the http headers to no-cache and cache-expire to some random date of the past, so that a normal user would see it anymore. Problem then is, that the image is downloaded everytime somebody visits the website..
You need to approach the HTML5 Application Cache in a different way. It is not useful for caching server-side dynamically generated pages, especially those that require a login to reach. The Application Cache has no concept of logins, nor securing a page from somebody with a different/no login.
It is much more appropriate for an AJAX-based site, where all HTML/CSS/JavaScript is static and registered in the Application Cache, and data is instead fetched via AJAX then used to populate pages. If you need to cache data in the application for offline use, then use one of the offline data storage mechanisms such as Local Storage/Session Storage, or IndexedDB, for data.
You can then make your own judgement on how much data you want to cache offline, since there's no way to validate a login without making a call to the server that is naturally inaccessable whilst offline.
What if when the user logs out or is not logged in they get a manifest with only network:*
I want our app to show the online help page (so it's always up to date) or even a local page. However, it's likely to be blocked by the Firewall (Zone Alarm).
BTW, I tested this with Zone Alarm. It blocked access to a local .html file as well as to an .asp file on the internet. (I.e., tried to display a page in Internet Explorer and got the Zone Alarm dialog asking if I wanted to give permission to display
Is there a way around this?
Perhaps displaying the web page in the Web Browser Control?
It's actually very unlikely that web traffic is blocked at the firewall (unless you mean the file type is blocked?). What you may need to do in such a setting, however, is use the same proxy that IE uses, because direct traffic may be blocked.
The simplest way to do that is to use a high level windows API or IE itself, and HTTP download the latest helpfile if there is a new one - these mechanisms should know about any proxy.
Of course, your users may not be using IE, even if most are. So you might need to allow the user to specify the proxy, or be able to auto configure the proxy in the same way that the browser does it.
edit: I see you mean zonealarm is part of the problem. yes, that is tricky as you will have to either get your application 'blessed' centrally by whoever manages zonealarm in the customer organisation, or (if there is no central management) then the user will have to allow the app to communicate. Perhaps you should bite the bullet and have the online help simply be a website, and spawn the preferred browser via 'executing' the URL as suggested in another answer.
If the web browser isn't blocked the firewall then they probably open port 8080 for any app and thus your app shouldn't be blocked.
If the firewall only allowed port 8080 to IE; you would have to punch a hole in the firewall to use a new browser like firefox or chrome.
To open a web page using the user's preferred browser (with appropriate proxy and authentication settings), use something like ShellExecute with the URL of the document to load. Something like this would do it (where page is the URL to load):
HINSTANCE r = ShellExecute(NULL, "open", page, NULL, NULL, SW_SHOWNORMAL);