After the transfer of the site to a new hosting, there is a problem: the site produces an event redirect to the old hosting. Currently set up nginx on something that would have sent data to pure servers but it produces still a redirect. The redirect itself is made starting from the app file.php to HttpKernel.php in handler (......) there is a call to events, $this->dispatcher - >dispatch(.................) which forms a redirect and does not let on, if you remove this element, then the page is formed only without data from the database and there is an error 404 page not found. When the page loads, a kernel event is generated.request and security.authentication.success and with such parameters it produces a redirect.
Check for kernel request events. You may have a hardcode somewhere. I dont know much about your symfony version, but you can debug events with php bin/console debug:event-dispatcher kernel.exception. After you do this post code here we might be able to help. AND YES question is formed very poorly.
Related
I am using Guzzle to pull data from content that the end location of a google rss feed link. e.g.
https://news.google.com/rss/articles/CBMiVWh0dHBzOi8vd3d3LmxvbmRvbi1maXJlLmdvdi51ay9pbmNpZGVudHMvMjAyMy9qYW51YXJ5L21haXNvbmV0dGUtZmlyZS1zdHJlYXRoYW0taGlsbC_SAQA?oc=5
When using curl with -L (location) flag it appears to bypass the consent redirect and pulls through the end location content.
I am using Drupal 10 with httpclient available which I understand uses Guzzle 7. How do I do the same there?
When enabling 'track redirects' guzzle feature I can see it appears to be getting stuck redirecting to google consent page and not redirecting to the end location?
e.g.
An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: /batch?id=328&op=do_nojs&op=do StatusText: parsererror ResponseText: Redirecting https://news.google.com/rss/articles/CBMiTmh0dHBzOi8vd3d3Lm15bG9uZG9uLm5ld3MvbmV3cy9wcm9wZXJ0eS9pbS1lc3RhdGUtYWdlbnQtcmVudGluZy1zb3V0aC0yNjA2MDI1ONIBUmh0dHBzOi8vd3d3Lm15bG9uZG9uLm5ld3MvbmV3cy9wcm9wZXJ0eS9pbS1lc3RhdGUtYWdlbnQtcmVudGluZy1zb3V0aC0yNjA2MDI1OC5hbXA?oc=5 to https://consent.google.com/m?continue=https://news.google.com/rss/articles/CBMiTmh0dHBzOi8vd3d3Lm15bG9uZG9uLm5ld3MvbmV3cy9wcm9wZXJ0eS9pbS1lc3RhdGUtYWdlbnQtcmVudGluZy1zb3V0aC0yNjA2MDI1ONIBUmh0dHBzOi8vd3d3Lm15bG9uZG9uLm5ld3MvbmV3cy9wcm9wZXJ0eS9pbS1lc3RhdGUtYWdlbnQtcmVudGluZy1zb3V0aC0yNjA2MDI1OC5hbXA?oc%3D5&gl=GB&m=0&pc=n&hl=en-US&src=1 Redirecting https://consent.google.com/m?continue=https://news.google.com/rss/articles/CBMiTmh0dHBzOi8vd3d3Lm15bG9uZG9uLm5ld3MvbmV3cy9wcm9wZXJ0eS9pbS1lc3RhdGUtYWdlbnQtcmVudGluZy1zb3V0aC0yNjA2MDI1ONIBUmh0dHBzOi8vd3d3Lm15bG9uZG9uLm5ld3MvbmV3cy9wcm9wZXJ0eS9pbS1lc3RhdGUtYWdlbnQtcmVudGluZy1zb3V0aC0yNjA2MDI1OC5hbXA?oc%3D5&gl=GB&m=0&pc=n&hl=en-US&src=1 to https://news.google.com/rss/articles/CBMiTmh0dHBzOi8vd3d3Lm15bG9uZG9uLm5ld3MvbmV3cy9wcm9wZXJ0eS9pbS1lc3RhdGUtYWdlbnQtcmVudGluZy1zb3V0aC0yNjA2MDI1ONIBUmh0dHBzOi8vd3d3Lm15bG9uZG9uLm5ld3MvbmV3cy9wcm9wZXJ0eS9pbS1lc3RhdGUtYWdlbnQtcmVudGluZy1zb3V0aC0yNjA2MDI1OC5hbXA?oc=5&ucbcb=1 Redirecting https://news.google.com/rss/articles/CBMiTmh0dHBzOi8vd3d3Lm15bG9uZG9uLm5ld3MvbmV3cy9wcm9wZXJ0eS9pbS1lc3RhdGUtYWdlbnQtcmVudGluZy1zb3V0aC0yNjA2MDI1ONIBUmh0dHBzOi8vd3d3Lm15bG9uZG9uLm5ld3MvbmV3cy9wcm9wZXJ0eS9pbS1lc3RhdGUtYWdlbnQtcmVudGluZy1zb3V0aC0yNjA2MDI1OC5hbXA?oc=5&ucbcb=1 to https://news.google.com/rss/articles/CBMiTmh0dHBzOi8vd3d3Lm15bG9uZG9uLm5ld3MvbmV3cy9wcm9wZXJ0eS9pbS1lc3RhdGUtYWdlbnQtcmVudGluZy1zb3V0aC0yNjA2MDI1ONIBUmh0dHBzOi8vd3d3Lm15bG9uZG9uLm5ld3MvbmV3cy9wcm9wZXJ0eS9pbS1lc3RhdGUtYWdlbnQtcmVudGluZy1zb3V0aC0yNjA2MDI1OC5hbXA?oc=5&ucbcb=1&hl=en-GB&gl=GB&ceid=GB:en
This appeared to be working fine prior to updating to d10 that also includes symfony 4-6 update behind the scenes, so not sure if that is related?
After looking into this a little more I believe the issue I was having is more to do with Google using Javascript to handle the redirect. I have tested this by turning javascript off in the browser and doing so the redirect does not work. This is in combination with all News links in rss feeds now linking to Google first rather than the final source.
So to overcome this I have had to add an additional step that extracts the url from this middle page which I can then use to do the final lookup.
I'm working on a WordPress website: https://samarazakaz.ru/
The client discovered a strange bug. After newly opening a browser the first login always fails, second one succeeds.
I tracked down the issue to a strange cookie with the name RCPC that is being set when the login form is submitted. If the cookie is missing then the login fails regardless of proper credentials.
I searched high and wide for any information about this cookie but could not find anything useful. The only thing remotely resembling my case was on some discussion on a site called https://codeforces.com/ . But nothing on that mentioned anything related to WordPress.
The site has a bare-bones setup with Elementor and my own plugin. And nothing in my code messes with cookies or the login process. I downloaded all website files and search in all files for "RCPC" but found nothing.
The site is behind an Nginx proxy, but I could not find any connection with this cookie and Nginx either.
I noticed that the value of this cookie is constant. So, as a workaround I jerry-rigged my plugin to set this cookie any time when it's not set. But, of course, I'm not very happy with that solution because I don't know if this will just stop working one day.
Update:
I verified that this is coming from the hosting. I renamed the /wp-login.php file and made a request to it, and it didn't return a 404 error but a 200 page with the same redirect code and the header to set the cookie. The hosting is reg.ru .
As far as I can figure this is a counter measure against automated password guessing. Any request (POST, GET, etc) to the /wp-login.php will get the redirect script with the cookie setting header. Only requests containing the correct RCPC cookie will get forwarded.
Upon further testing found that the value of the RCPC cookie is some kind of hash generated from the request's IP address. Because all of our computers got the same one but from other locations its different.
This does not cause any problem if the standard WordPress login form is used because that lives at the /wp-login.php address, so the first GET request will generate the cookie. However, we had a custom login page which didn't access /wp-login.php until the form was submitted.
Based on these discoveries I made a workaround, which is simply adding a one line JS script to the login page which makes a (fetch) request to the /wp-login.php page and simply discards the result. This is enough to set the cookie in the browser so that the form will work at the first try.
Need on hosting disable test-cookie-module
Have to admit I am a Symfony newB. Generally, I do know what I am doing but I am stumped with this problem.
I have been given a pair of packages to maintain. One side is a front end written with Angular.js. Then there is the backed written using Symfony.
After installing the backend portion, using composer. I am now trying to test.
The front end seems to be good when it fires up at xxx.yyy.com/app. Its first screen is a login screen where it asks for username and password. The submit button fires off a request of xxx.yyy.com/api/users/token. The username and password from the screen are stored in the http request as json.
Once the request is made I have determined that app.php in the symfony code fires off and starts the user authentication process. After a lot of work in trying to debug through the code, I can see that the symfony backend does have the user name and password and knows that the request is a POST request in good form. However, I keep getting the error "Route Not Found" and then am kicked out of symfony.
There is every reason to believe the code is written correctly and the problem lies in something I have done to install the code. When I run the debug:router process, I can find the route as a correct one. But, this route is never found. I have also tried other routes with the same result.
Can anyone suggest a reason why routes shown in the debug:router process do not work in actual use? I am really stumped and would appreciate some suggestions.
Think I am really on to the problem. It's the way that the front end javascript is creating the URL for the backend along with the way my server is configeured.
My front end is xxx.kjitx.com/app This code is then adding the base URL to the command for the backend to form a request of xxx.kjitx.com/api/users/token Then when my backend receives control it is stripping off the xxx.kjitx.com/api part of the url and sending the users/token string to the router. The router is looking for /api/users/token so the routing fails. In the handshake I lost the first piece, api, of the route. Found this out by forcing the front end to add an extra piece of api, i.e. xxx.kjitx.com/api/api/users/token and it works.
Now I just need to go back into my code to properly set up my addressing so I don't loose an important part of the address.
Does the app use CORS?
Perhaps you have to whitelist your dev domains
So, from here...
In ASP.NET, you have a choice about how to respond to that - it's in the web.config as CustomErrors. Turn that on, then redirect to a fancy 404 page (maybe you already do). The fancy 404 page, then, could be checking the requested querystring (which gets passed over to the custom error page as yet another querystring) to see if it's a valid redirect, lives in your database, etc. Just do a Response.Redirect() from there.
Then schooner writes:
Thanks, we do have a 404 now but we would prefer this not to be detected as a 404 in the process. We would like ot handle it directly and seperately if possible.
..and I'd like to know just how bad a practice this is. I don't expect to put my "pretty" URLs on the internet (just business cards) and I have a sample of 404-redirecting-to-a-helpful-site code working, but I don't want to get to production and have an issue with a browser that takes the initial 404 too seriously. Can anyone help me understand more about why I wouldn't want to use customErrors / 404 to flow users to the page they actually wanted?
The main problem with using customeErrors as your 404 error handler is that every time customErrors picks up an errored request rather than throwing a 404 error back to your browser and letting your browser know there was a bad request, it instead returns a 302 which indicates that a page has been relocated to whatever your customErrors page is. This isn't bad for most users because they don't know or even notice the difference, the problem comes from the fact that web crawlers DO know the difference and the status code they receive directly affects how their indexing works.
Consider the scenario where you have a page at http://mysite.com/MyAwesomePageAboutStuff.aspx for some period of time and then one day you decide you no longer need it and delete the file. If Google or some other crawler has already indexed that URL and goes back to it after you delete it the crawler will get a 302 status code instead of a 404 error and because of this status code the crawler will update the page's url to point to your error page rather deleting the non-existent link. Now, whenever someone finds that url by way of a search engine they'll end up at your error page.
It's not really a huge issue, but you can definitely see the headaches this can create for your users in the long run.
Look here for some corroborating data.
I created a vanity url system using the 404 as the handler. There's no need for a 302 on my side as the 404 dynamically loads the content and returns that. I am fully able to handle any and all POST / GET and SERVER data.
Works great. If you are interested TarantulaHawk is up on SourceForge.
I'm replacing an old web application with a new one, with different structure.
I can not change the virtual directory path for the new app, as I have users which have bookmarked different links to the old app.
Lets say I have a user, who has this bookmark:
http://server/webapp/oldpage.aspx?data=somedata
My new app is going to reside in the same virtual directory, replacing the old one, but it has no longer oldpage.aspx, instead it has different layout, but it still needs the parameter from the old url.
So, I have set to redirect 404 errors to redirectfrombookmark.aspx, where I decide how to process the request.
The problem is, that the only parameter I receive is "aspxerrorpath=/webapp/oldpage.aspx", but not the "data" parameter, and I need it to correctly process the request.
Any idea how I can get the full "original" url in the 404 handler?
EDIT: reading the answers, looks like I did not make the question clear enough:
The users have bookmarked many different pages (oldpage1, oldpage2, etc.) and I should handle them equally.
The parameters for each old page are almost the same, and I need a specific ones only.
I want to re-use the "old" virtual directory name for the "new" application.
The search bots, etc., are not a concern, this is internal application with dynamic content, which expires very often.
The question is - can I do this w/o creating a bunch of empty pages in my "new" application with the old names, and Request.Redirect in their OnLoad. I.e. can this be done using the 404 mechanism, or some event handling in Global.asax, etc.
For the purposes of SEO, you should never redirect on a 404 error. A 404 should be a dead-end, with some helpful information of how to locate the page you're looking for, such a site map.
You should be using a 301, moved permanently. This allows the search bots to update their index without losing the page rank assigned to the original page,
See: http://www.webconfs.com/how-to-redirect-a-webpage.php on how to code this type of response.
You could look into the UrlRewritingNet component.
You should also look into using some of the events in your Global.ascx(?extention) file to check for errors and redirect intelligently. The OnError event is what you want to work with. You will have the variables from the request at that point in time (under the HttpContext object) and you can have your code work there instead of a 404. If you go this route, be sure you redirect the 404 correctly for anything other than oldpage.aspx.
I am sorry I don't have any explicit examples or information right now, hopefully this will point you in the right direction.
POST and GET parameters are only available per request. If you already know the name of the old page (OldPage.aspx) why not just add there a custom redirect in it?