Is it possible to render another page instead of one currently being processed?
For instance, my plugin detects 404 error, sets corresponding HTTP headers, and then outputs a normal page from website - but under those HTTP 404 headers, so the browser and search engines will receive custom, good-looking 404 page.
Redirecting by
<? header("Location: ...'); ?>
is not an option. I need stop rendering current page and render another, but display it under this, non-existing url.
How this can be done?
Sounds like you need a system event plugin, please see:
http://docs.joomla.org/Plugin/Events/System
in particular, the onAfterDispatch method:
http://docs.joomla.org/Plugin/Events/System#onAfterDispatch
The onAfterDispatch method is called after routing, and after Joomla has determined whether the url is valid, so it should be the time to get involved and redirect to another page.
Related
I have created the project which has login page login.blade.php which has only Regno to login-in.
once it login is the success it will redirect to home.blade.php and it followed by 4 more pages when clicking of next button in each page
page2.blade.php,page3.blade.php,page4.blade.php,page5.blade.php and finally, it should redirect to login page itself. The problem is the browser back button should not allow it to go back to the previous page.
can anyone suggest me how to create middleware for this?
thank you.
The browser's back button is not controlled by the server, where Laravel runs. There is no way for you to block it or interact with it in any way inside your PHP code.
What you can do is send XMLHHTTPRequest (XHR) with JavaScript. They ensure that on a button click you will stay on the same page in the browser and then your JS-code can read the server response (your rendered page templates) and replace the current content with the one from that response. You can read more on this when you google for AJAX, e.g. this article: https://www.sitepoint.com/use-jquerys-ajax-function/
Read this thing. I once implemented in the same way. By setting cache control in response header.
https://stackoverflow.com/a/51821808/10239067
Ruby method send_file itself redirects to file to server.
But I want to customize that redirection and need to redirect to another page.
The way a redirection of this type is performed is using the Location header in the HTTP response. You cannot return content and a redirect in the same response.
What you can do, however, is link to a page that performs the download after a short amount of time, and then redirects.
Have a look at the HTML Meta Refresh feature.
My web app runs under Tomcat, it uses AJAX requests very intensively, and during the development process I have to redeploy the web app intensively too. After the redeployment I usually simply refresh the page knowing that the user session is dropped, but I always get to the scenario described below:
Go to some page, a really big page with many JS-scripts included, that actually makes those intensive AJAX requests.
Stop Tomcat or redeploy the web app.
Refresh the page.
Enter the credentials in the sign-in form to authenticate.
Suddenly get the last AJAX request response in the browser window and the AJAX request URL in the URL bar.
Wow... It looks strange for me that AJAX request URLs appear in the URL bar along with their response in the web page display area. This actually happens to Firefox and Chrome (haven't tested it in other browsers). Unfortunately, I cannot reproduce the same behavior in a simple page written from scratch. Frankly speaking, I don't really understand what happens to such requests and why do browsers "think" if AJAX requests/responses are entered in URL bar by user...
Your possible explanations or hints for such a strange behavior are very and very appreciated. Thanks!
(Perhaps it can help: All AJAX requests are performed with jQuery 1.4.2)
I'm very sorry, as I understood later, the question is not complete, because there was another pitfall I didn't mention, so no one couldn't answer the question in principle. The reason of the bug was hiding in the... <body onunload="..."> tag definition. That was quite unexpected, but that code contained some AJAX request that must be invoked when a user leaves the page. I only realized that the authenicating module (FORM, j_security_check) returned a response (HTTP 302) containing the Location header - so that was the reason why browsers did redirects.
The exact scenario was like that:
Open the page containing <body onunload="some_ajax_here">.
Log out the app using another tab so you could stay at the same page.
Refresh the page so some ajax could be invoked - this AJAX request is not now allowed because it's a secured part of the application (you get the forwarded content of the login page).
Enter the credentials and now oops you get to the result of some ajax directly in the browser window.
As the quick fix, and I hope the final one, I added another request following that AJAX request:
$.ajax({
async: true,
method: "GET",
url: document.location.pathname + document.location.search
});
So the HTML page script simply makes self-page request the last one - j_security_check returns the Location referring the last used HTML page, and the redirect works fine. Perhaps my explanation is not clear and may be not complete or even full of mistakes, but it looks like that in general. I'm very sorry once again, and thank you #ChristopherSchultz!
I am using an .htaccess custom error page "error.php". Problem is, all it does is just redirect them.
I would like for my 404 to display the requested URL in the address bar, as if the user was never redirected.
Here are a few model examples:
http://us.battle.net/wow/en/22222222222222222222
http://en.wikipedia.org/wiki/222222222222222222222
Are these pages simply using a URL rewriter that is in actuality something like "domain.com/index.php?page=2222222222222222222222" ? If so, are they just printing out text without indicating that it is a 404 page without marking it as an error page somehow?
They have to be sending something in the header. I have a Chrome Extension for the +1 button, and when I go to the listed pages, it gives me an error saying "Cannot +1 this page."
Does anyone have any idea what "flag" is being used here?
Yes, you can send HTTP status codes using the pre-processor which determines that the page doesn't exist. For example, in PHP you would use this:
header('HTTP/1.1 404 Page Not Found');
This would send the 404 header along with the custom 404 page you want to display. You can do this with any HTTP status code, even make up your own (though they probably won't be recognized).
header('HTTP/1.1 418 I'm a Teapot');
If you use Apache's ErrorDocument definition in your .htaccess file, it should maintain the error code so long as you do not modify the headers with the page defined (such as running a PHP file) or redirect to a new page. Using plain text and/or (possibly) a HTML file would preserve the 404 header. I have never tested it with an HTML file.
Greetings,
Here's the problem I'm having. I have a page which redirects directly to another page the first time it is visited. If the user clicks 'back', though, the page behaves differently and instead displays content (tracking session IDs to make sure this is the second time the page has been loaded). To do this, I tell the user's browser to disable caching for the relevant page.
This works well in IE7, but Firefox 3 won't let me click 'back' to a page that resulted in a redirect. I assume it does this to prevent the typical back-->redirect again loop that frustrates so many users. Any ideas for how I may override this behavior?
Alexey
EDIT: The page which we redirect to is an external site over which we have no control. Server-side redirects won't work because this wouldn't generate a 'back' button for in the browser.
To quote:
Some people in the thread are talking about server-side redirect, and redirect headers (same thing)... keep in mind that we need client-side redirection which can be done in two ways:
a) A META header - Not recommended, and has some problems
b) Javascript, which can be done in at least three ways ("location", "location.href" and "location.replace()")
The server side redirect won't and shouldn't activate the back button, and can't display the typical "You'll be redirected now" page... so it's no good (it's what we're doing at the moment, actually.. where you're immediately redirected to the "lucky" page).
I think the Mozilla team takes a step into the right direction by breaking this particularly annoying pattern. Finding a way around it somehow defies the purpose, doesn't it?
Instead of redirecting on first encounter, you could simply make your page render differently when a user hits it the first time. Should be easy enough on the server side, since you already have the code that is able to make that distinction.
You can get around this by creating an iframe and saving the state of the page in a form field in the iframe before doing the redirect. All browsers save the form fields of an iframe.
This page has a really good description of how to get it working. This is the same technique google maps uses when you click on map search results.
I'm strongly in favor for the Firefox behaviour.
The most basic way to redirect is to let the server send HTTP status code 302 + Location header back to the client. This way the client (typically a browser) will not place the request URI into its history, but just resend the same request to the advocated URI.
Now it seems that Firefox started to apply the bevaviour also for server responses that try redirections e.g. by Javascript's onload event.
If you want the browser not to display a page, I think the best solution is if the server does not send the page in the first place.
Its possibly in aide to eliminate repeated actions.
A lot of ways people do things is
page 1 -> [Action] -> page 2 -> redirect to page 2 without the action parameters.
Now if you were permitted to click the back button in this situation and visit the page without the redirect, the action would be blindly re-performed.
Instead, firefox presumes the server sent a redirect header for a good reason.
Although it is noted, that you can however have content delivered after the redirect header, sending a redirect header ( at least in php ) doesn't terminate execution, so in theory, if you were to ingnore the redirect request you would get the page doing weird stuff.
( I circumvent this by the fact all our redirects are done via the same function call, where i call an explicit terminate directly after the redirect, because people when coding assume this is how it behaves )
In the URL window of firefox type about:config
Change this setting in firefox
browser.sessionstore.postdata
Change from a 0 to 1