I am very confused, so please bear with me on this one.
I have a CakePHP web application (v3.8) and for some reason, it does not have a /http/ folder...I didn't develop the base part of the app, and for reasons I can't go into, I can't contact the developer.
This usually does not matter since the site works great! My issue is that we run IP logging so users can see IPs that have logged into their accounts. We started using Cloudflare, and now we are logging Cloudflare's IPs instead of actual user IPs. My research brought me to this page, but the file referenced that I need to change does not exist. The file that needs to be changed is /http/serverrequest.php, and the file does not exist.
Any help would be appreciated, I am a bit over my head with this one, but it seems like if I can find (or create) that file, and set the proxy setting to true, the IP logs will work. My main concern is if I am missing something and that isn't a good solution for whatever reason, which is why I am asking for help! Thanks again in advance!
Thanks to ndm's comment, I found the file in /vendor/cakephp/cakephp/src/Http and was able to make the changes there.
Related
I received email from Google search console saying my website contains social engineering contents. Sample URL is,
http://www.sanenthusiast.com/~stechies/Blessin/ba/index.php
Safety tip For your own safety do not type anything in the page.
Somebody hosted a mockup site of Google drive login page on these links. How to get rid of this? I have thoroughly checked my webserver an I dont see any of these folders or files. Looks likes ~stechies/ could be some other webserver and I guess using Apache they have pointed ~stechies/Blessin/ba/index.php and ~stechies/Blessin/ba/ to my webserver sanenthusiast.com/?
Is this correct? It will be of great help if someone could help to stop this redirection.
I checked who owns stechies and found https://www.stechies.com/ Are they behind this phishing scam? Or possibly someone else has hacked them?
Edit:
Another user in stackoverflow posted similar issue on his site - Someone put malicious code with "~" on my website
Tried all possible ways to mitigate the issue. But it was very hard to get rid of the URL redirect. My site runs on WordPress. I can confirm that WordPress was intact and not compromised. The possible issue is with the hosting account or the hosting provider itself.
Checked hidden file in the hosting account root directory, no where ~stechies/Blessin/ba/ to be seen. Finally I ended up migrating to a new hosting provider. Copied only mail and WordPress backup. Once done, the URL redirect is not working now. Submitted my site again for review and Google cleared the error and no more warning comes up.
This still not a effective solution but Google reporting Social engineering content on the site caused panic and I had very less time to respond.
I have a use case where I need to be able to access my site from the local server. Specifically, it's for a HTML-to-PDF export of parts of various pages, but this would be nice for testing parts of the website as well.
The problem is that we have a login splash page, which needs to be dealt with before I can access any parts of the website. It would be really nice if I could just call a command "wkhtml2pdf 'localhost/[myurl]'" and have it PDF some stuff, but it hits this splash page.
Is there some way that I can perma-persist just one single session on the server? Or enable login-less access from localhost? Or could I just add a new Apache entry that accesses our site, whitelists only localhost and somehow circumvents the login?
What's the best solution?
You can pass your session cookie as parameter in wkhtml2pdf to solve your problem.
You can also execute it from a php file like this.
exec("wkhtmltopdf --cookie '{$cookieName}' '{$cookieValue}' http://example.com");
Soliciting feedback on this solution now:
I whitelisted localhost via $_SERVER['REMOTE_ADDR'] in the login scripts to bypass the usual user authentication and get an automatic localhost-user login. The server is running, however, on a university LAN, so the LAN maybe really big, possibly enabling bidirectional TCP spoofing.
Should I be worried about this, or does someone need admin rights on the routers or something? I trust the IT folks, but not others.
I realize that this sounds like a separate question, but I feel that security relates to whether or not this is a good solution.
I am really new to Drupal and playing around with this existing Drupal site.
I did a FTP transfer of all the files to my local computer directory. I currently got it on a Vagrant box and I can access the site via http://192.168.56.101/html.
I can do http://192.168.56.101/html/anything-but-user and it brings me to the proper area on the site. However I can't do localhost/html/user, because it redirects me to the website URL rather than the local URL.
I tried clearing the cache (with Drush). I scanned all files in the system and changed the web url to the local URL [not sure if I need to do any other command], and I can't seem to find anything in the .htaccess files that would lead me to this.
The href="/user I would greatly appreciate any advice or help in figuring out this solution.
--UPDATED
There was a module called "Secure Pages" that was causing the user and registration links to be locked and static to prevent redirects to phishing sites. I had to disable this module using "drush pm-disable securepages" in the terminal.
Some typical items you may want to check:
Check if you get the same problem using another browser. If with another browser it works, then it is pretty sure a cookie problem. To solve that, delete the cookie in the browser where you have the problem.
Make sure "clean urls" is enabled. Refer to "https://drupal.stackexchange.com/questions/165029/clean-url-leads-to-duplicate-url-after-migration-to-another-hosting/165044?s=1%7C3.9647#165044" for more details on that.
Make sure the value of "base_url" is set correctly (in your settings.php).
If module Secure Pages is enabled, then try to (at least temporary) disable that moduel to see if it helps.
Apparently, there was a mod called "SecurePages" that was causing the URLs to be static to prevent someone from changing them and redirecting users to a phishing site.
We run a staging and live environment and I would like to prevent my editors to login into the live website.
However, every time we push the staging -> live, the users are synchronized, so creating different users on different environments is not a possibility since we are pushing the staging daily.
Today one of the editors logged in to the live website by mistake and messed up the HTML and broke the homepage.
I think the way to go is to just "disable" certain users in the LIVE environment which can be detected by the domain, URL or path.
The way I see it is basically a plugin that will add a check-box ("allow to login to LIVE") to the users page.
The plugin will just need a setting page where you enter the LIVE URL (any other domain would be considered staging).
From there I just have to code the logic to prevent logging in by comparing domain (staging or live) and the flag on the user.
My question is does anybody had this problem before and how did you solve it? Also if somebody has already coded what I'm talking about, the code would be really appreciated.
Thanks!
Well guys, I had to go ahead and build the plugin.
If somebody has the same problem, then I made a Wordpress plugin that you can download here
Thanks for reading.
Initially I had the issue reported in this question.
Now, what I noticed is that there are some browsers that accept the password, and there are some which don't. Difference? For some reason the cookie is generated when I log in into the Administration module, but it isn't when I write down the password to access the page, forcing it to simply reload.
I can see the cookie created for the log-in, but I can see none for the password-protected Page.
These happens on Internet Explorer, both version 7 and 8; only on some machines, though, but most of them fail this. I already tried white-listing the URL, and even letting it accept ALL cookies, to no avail.
What may be the cause? If perhaps it's got something to do with question above, please help me!
Thanks in advance.
PS: If you know of another, cookie-free method to make a simple authentication, please link me to it. Thanks. Oh, and by the way, this is inside an Intranet with static, class C IPs.
Assuming you're on an Apache server, consider this authentication module for Wordpress that allows for a far more flexible approach:
http://wordpress.org/extend/plugins/http-authentication/
This module allows you to Bypass WordPress' normal authentication and use Apache's authentication instead - So pretty much any auth you'd like to use.
You can find more information on Apache Authentication methods here:
http://httpd.apache.org/docs/1.3/howto/auth.html#database
I've pointed at the database section as I'm assuming you'll want to use a database to authenticate.