I need to redirect (after do something) to an URL from doView().
How is it possible?
Many thanks in advance,
From your tags I'm assuming you're writing a portlet, possibly including an actionhandler. Now as soon as you're coming to the render phase, you intend to redirect to a completely different URL (e.g. to redirect your browser to show something outside of the portal) - correct me if I'm wrong.
With this, HTTP redirect is out of the game if you want this to work reliably. (There has been a lively debate on the liferay forums on the reasons)
For this reason javascript is your friend if you intend on the redirect to happen during render phase. However, note that this still might interfere with user expectation: Imagine if two different portlets generate different javascript redirects - which one do you expect to win?
Architecturally it might be cleaner to trigger a redirect during the action phase, but that's not your question
Related
I would like to have the following setup using .htaccess.
domain.com/test/hello.php or domain.com/index.php or any other link must show only domain.com in the URL.
Kindly share your views on this.
As implied by Jon Lin, this is not directly possible as the server cannot guess what content should be loaded. The simple rule of HTTP is that each request has its own response.
Furthermore, it should be noted that, if it were possible (by some kind of magic - perhaps by the use of AJAX), it wouldn't be good for SEO, as Google/Bing/whatever wouldn't be able to index your site.
If you really wanted to mimic the behaviour, you could run the following HTML5 History API method in JavaScript:
window.history.pushState("", document.title, "/");
This will change the address bar to show only your domain name, and will more than likely have side-effects.
this is a broader question than I would probably ask of the CartThrob folks, which is why I'm posting it here. What would the community recommend as far as SSL is concerned with CartThrob? The store functions are limited to a couple of key template groups. So my thinking was perhaps the best way to handle it would be htaccess on the basis of the presence of those URL segments. I would like to return the user to a non-SSL connection when they are not in the store area. So a trigger might be the first segment being "basket" or "account" for example. Or what about an in-template redirect to the secure URL? Very interested to hear the community's suggestions on how best to handle SSL within a given area of an EE site. I'm interested in whatever makes the most sense to implement, while also ensuring that, for example, all assets - even those loaded with path variables - are loaded via SSL. Thanks all!
I've always used CartThrob's https_redirect tag (docs) on my checkout screens, which will rewrite your {path}, {permalink} (etc)-created URLs to use https, as well as redirect you to the https:// version of your page if necessary.
That, combined with using the protocol-agnostic style of calling scripts and stylesheets should get you most of the way in getting your secure icon in the browser.
(Example:)
<script src="//ajax.googleapis.com/ajax/libs/jqueryui/1.9.1/jquery-ui.min.js"></script>
I know there are some advantages in using page forwarding as it is the default in JSF.
I also know how to set redirect for some pages using 'faces-redirect' in the implicit navigation or the tag in the faces-config file.
I searched a lot on internet but I didn't find an easy and straight way (such as a configuration parameter) to enable redirect for all pages.
The reason I would like to use page redirect everywhere is the following: if every page is asked whit its url the container can be used for page authorization without the need of additional security library. Don't know if it can be a good idea, but performances are not an issue in this moment and using container security can save development time for the first release.
You can achieve this with a custom ConfigureableNavigationHandler. You can find a kickoff example in the answer to this question: JSF 2 and Post/Redirect/Get?
However, I have the feeling that you're designing page-to-page navigation the wrong way. You seem to be using POST requests for simple page-to-page navigation. If you fix them to be GET requests, then you don't need to worry about this. So, use <h:link> instead of <h:commandLink> for page-to-page navigation. This way you don't need to implement the PRG. See also When should I use h:outputLink instead of h:commandLink?
I'd like to know how websites have created URLs with other domains like these on trafficestimate.com.
I'm guessing it's some .htaccess stuff to redirect domain names to a dynamic page?
Thanks
Your URL has an GET Request. So when someone calls the page http://google.com/search with the parameters hl=en, safe=off etc., the page can process those parameters. So for instance safe=off means that you want to get back any search result. The q=site:... is your search string. In this case Google will look it up in its database and give you the results. So when you call this URL there is probably no .htaccess processing done. However you can process the URL and GET request with .htacces and i.e. redirect the user to another page.
Maybe you'll describe a bit further what exactly you trying to do/want to know. This makes explaining easier.
EDIT: After reading Gumbo's comment I looked at the Google result page. So maybe your question means the trafficestimate-URLs. They look like http://trafficestimate.com/example.org. This is really a good case for .htaccess. So using .htaccess they take the URL and redirect it to http://www.trafficestimate.com/websites/?domain=example.org. Here you have again a GET request and an application builds the page.
Some URL rewriting is probably involved. Otherwise they would have to create an existing file for every possible request.
Using Apache’s mod_rewrite in a .htaccess file is one option. But since the server identifies itself with “Microsoft-IIS/7.5”, they are probably rather using ISAPI_Rewrite, a mod_rewrite derivative for Microsoft’s IIS.
I'm creating a site that allows users to add Keyword --> URL links. I want multiple users to be able to link to the same url (exactly the same, same object instance).
So if user 1 types in "http://www.facebook.com/index.php" and user 2 types in "http://facebook.com" and user 3 types in "www.facebook.com" how do I best "convert" them to what these all resolve to: "http://www.facebook.com/"
The back end is in Python...
How does a search engine keep track of URLs? Do they keep a URL then take what ever it resolves to or do they toss URLs that are different from what they resolve to and just care about the resolved version?
Thanks!!!
So if user 1 types in "http://www.facebook.com/index.php" and user 2 types in "http://facebook.com" and user 3 types in "www.facebook.com" how do I best "convert" them to what these all resolve to: "http://www.facebook.com/"
You'd resolve user 3 by fixing up invalid URLs. www.facebook.com isn't a URL, but you can guess that http:// should go on the start. An empty path part is the same as the / path, so you can be sure that needs to go on the end too. A good URL parser should be able to do this bit.
You could resolve user 2 by making a HTTP HEAD request to the URL. If it comes back with a status code of 301, you've got a permanent redirect to the real URL in the Location response header. Facebook does this to send facebook.com traffic to www.facebook.com, and it's definitely something that sites should be doing (even though in the real world many aren't). You might allow consider allowing other redirect status codes in the 3xx family to do the same; it's not really the right thing to do, but some sites use 302 instead of 301 for the redirect because they're a bit thick.
If you have the time and network resources (plus more code to prevent the feature being abused to DoS you or others), you could also consider GETting the target web page and parsing it (assuming it turns out ot be HTML). If there is a <link rel="canonical" href="..." /> element in the page, you should also treat that URL as being the proper one. (View Source: Stack Overflow does this.)
However, unfortunately, user 1's case cannot be resolved. Facebook is serving a page at / and a page at /index.php, and though we can look at them and say they're the same, there is no technical method to describe that relationship. In an ideal world Facebook would include either a 301 redirect response or a <link rel="canonical" /> to tell people that / was the proper format URL to access a particular resource rather than /index.php (or vice versa). But they don't, and in fact most database-driven web sites don't do this yet either.
To get around this, some search engines(*) compare the content at different [sub]domains, and to a limited extent also different paths on the same host, and guess that they're the same if the content is sufficiently similar. Of course this is a lot of work, requires a lot of storage and processing, and is ultimately not terribly reliable.
I wouldn't really bother with much of this, beyond fixing up URLs like in the user 3 case. From your description it doesn't seem that essential that pages that “are the same” have to share actual identity, unless there's a particular use-case you haven't mentioned.
(*: well, Google anyway; more traditional ones traditionally didn't and would happily serve up multiple links for the same page, but I'd assume the other majors are doing something similar now.)
There's no way to know, other than "magic" knowledge about the particular website, that "/index.php" is the same as fetching "/".
So, your problem, as stated, is impossible.
i'd save 3 link as separated, since you can never reliably tell they resolve to same page. it all depends on how the server (out of our control) resolve the url.