I have had an issue with setting up my gerrit server. The machine has Ubuntu 12.04 LTS Server 64-bit installed on it. I am setting up git and gerrit as a way to manage source code and code review.
I require internal and external access to it. I setup a DNS that would work externally. However, during the initial setup, i left the canonicalWebUrl to its default value. It usually take's the machine's hostname (in this case it was vmserver).
The issue I was running into is exactly as explained here https://stackoverflow.com/questions/14702198/the-requested-url-openid-was-not-found-on-this-server, where after trying to sign in/register account with OPEN ID, it was saying url not found.
For some reason, it was changing the url in the address bar from the the DNS i setup to the CanonicalWebURL.
I tried to change the canonical web url in the gerrit.conf file found in etc of the gerrit site. After restarting the server, however, we were able to see the git project files present as they should be, but the account that was administrator seemed to no longer be registered and none of the projects were visible through gerrit.
I was wondering if there was a special procedure to changing the canonical web url in gerrit without disrupting access to a server?
any help or information on canonical urls would be much appreciated as i cannot find too much information on them.
edit:
looking deeper, i found some information that is way over my head regarding "submodules"
i do not understand if this is what i am looking for or not.
https://gerrit-review.googlesource.com/#/c/36190/
The canonical web url must be set, and it sounds like you have done that correctly.
I suspect the issue you are seeing is caused by changing the canonical web url - some OpenID providers (Google being the big one) will return a different user ID based on the URL of the request. This is a privacy thing and cannot be changed. So previous users will now show up as new users and won't be in their old groups (Administrators group in this case).
If you don't have many users, it might be easiest to migrate them by hand. You can modify the database to map the new user ID to the old user account.
Related
from the documentation it seems that I have to edit the server.xml file to set: proxyName, proxyPort, scheme.
Not only doesn't it explain what those settings are for, but I also can't find any motivation behind it. Doesn't the usual apache reverse proxy configuration just suffices?
The specific parameters you refer to in server.xml file are Tomcat <Connector> attributes.
The practical impact is that Jira or third-party apps will sometimes use these attributes to construct fully-qualified URLs to refer back to Jira, and which also sometimes get passed on to the client browser. The attributes configured here should match the base URL configured in the main Jira system configuration.
For example, Jira may send redirects to the user's browser if it detects that you are accessing Jira from something other than the canonical URL as configured here. It will also occasionally construct fully-qualified URLs (rather than relative URLs) in certain parts of the application.
You also generally need to have correct values set for these attributes (as well as the base URL) if you want Application Links and the UPM (app manager) to work correctly.
For local testing or development purposes, it is generally acceptable to remove these attributes entirely (it will stop auto-redirection from happening), so long as you're always accessing Jira from the base URL, and knowing that you may have issues with AppLinks or the UPM. Removing them is certainly better than having an incorrectly-configured proxyName, which would otherwise generate redirects to the wrong place.
I'm using a domain name with this general structure: http://mydomainname.com/
However, when I click it, I get a 404 message saying:
And when I look in the URL, it's not http://mydomainname.com/ but surprisingly http://mydomainname.com/YkPWZ/.
How did YkPWZ/ appear automatically and what can I do to eliminate this issue? Sometimes accessing http://mydomainname.com/ works fine, but most of the time the browser automatically tacks on some random characters at the end of the URL, throwing the 404 message. This is not a browser-specific issue and I've had a few colleagues replicate this issue on different operating systems (both desktop and iOS).
P.S. If it matters at all, I generated my website using Github Pages (markdown files, not HTML).
I'm quite certain this is an issue on the GoDaddy side of things, though I'm unable to find any official documentation on the subject. As noted in comments above, the redirect isn't coming from GitHub Pages.
I found an old thread discussing the issue. Here is a brief summary:
GoDaddy may use redirects like this to handle load balancing on their shared hosting servers.
In several cases, users contacted GoDaddy to ask about the problem and
had the issue resolved, but
were never told the technical specifics of what was happening.
If you wish to stay with GoDaddy I recommend contacting them and sending them to the link I found above. They may be able to resolve the issue for you, though I wouldn't expect an explanation.
Alternatively, you can use another web host. In many circles, GoDaddy isn't rated very highly. It's lucky that there are so many web hosts to choose from. Alternatively, you can use a custom domain directly with GitHub Pages, bypassing a third-party host entirely.
I'm developing a Google Sheets add-on. The add-on calls an API. In the API configuration, a url like https://longString-script.googleusercontent.com had to be added to the list of urls allowed to make requests from another domain.
Today, I noticed that this url changed to https://sameLongString-0lu-script.googleusercontent.com.
The url changed about 3 months after development start.
I'm wondering what makes the url to change because it also means a change in configuration in our back-end every time.
EDIT: Thanks for both your responses so far. Helped me understand better how this works but I still don't know if/when/how/why the url is going to change.
Quick update, the changing part of the url was "-1lu" for another user today (but not for me when I was testing). It's quite annoying since we can't use wildcards in the google dev console redirect uri field. Am I supposed to paste a lot of "-xlu" uris with x from 1 to like 10 so I don't have to touch this for a while?
For people coming across this now, we've also just encountered this issue while developing a Google Add-on. We've needed to add multiple origin urls to our oauth client for sign-in, following the longString-#lu-script.googleusercontent.com pattern mentioned by OP.
This is annoying as each url has to be entered separately in the authorized urls field (subdomain or wildcard matching isn't allowed). Also this is pretty fragile since it breaks if Google changes the urls they're hosting our add-on from. Furthermore I wasn't able to find any documentation from Google confirming that these are the script origins.
URLs are managed by the host in various ways. At the most basic level, when you build a web server you decide what to call it and what to call any pages on it. Google and other large content providers with farms of servers and redundant data centers and everything are going to manage it a bit differently, but for your purposes, it will be effectively the same in that ... you need to ask them since they are the hosting provider of your cloud content.
Something that MIGHT be related is that Google rolled out some changes recently dealing with the googleusercontent.com domain and picassa images (or at least was scheduled to do so.) So the google support forums will be the way to go with this question for the freshest answers since the cause of a URL change is usually going to be specific to that moment in time and not something that you necessarily need to worry about changing repeatedly. But again, they are going to need to confirm that it was something related to the recent planned changes... or not. :-)
When you find something out you can update this question in case it is of use to others. Especially, if they tell you that it wasn't a one time thing dealing with a change on their end.
This is more likely related to Changing origin in Same-origin Policy. As discussed:
A page may change its own origin with some limitations. A script can set the value of document.domain to its current domain or a superdomain of its current domain. If it sets it to a superdomain of its current domain, the shorter domain is used for subsequent origin checks.
For example, assume a script in the document at http://store.company.com/dir/other.html executes the following statement:
document.domain = "company.com";
After that statement executes, the page can pass the origin check with http://company.com/dir/page.html
So, as noted:
When using document.domain to allow a subdomain to access its parent securely, you need to set document.domain to the same value in both the parent domain and the subdomain. This is necessary even if doing so is simply setting the parent domain back to its original value. Failure to do this may result in permission errors.
I just heard from my friend that open 3.0 is out.
I want to try this but I cannot access http://opencv.org/.
It says :
Coming soon: Another fine website hosted by WebFaction.
Site not configured
If you are the owner of this website and weren’t expecting to see this message, here are some potential causes and solutions:
You recently created a new website record, but opened the URL before your changes were activated in the web server and DNS configuration. Wait a moment and refresh.
You created a new website record without the current subdomain (for example, www). Return to the control panel to add the current subdomain to the website record and refresh.
You added a new domain in the control panel but didn’t create a site record to link it with an application. Create a website record with the control panel and refresh.
Your website record is set for HTTPS, but you visited a HTTP URL (or vice-versa). Open the URL with the other protocol.
You tried to access your website by IP address. Access the website by domain name instead.
There is a problem with your account. Check the control panel for unresolved support tickets and check your email for recent messages from support#webfaction.com.
For more details, please see Error: Site not configured.
I'm sure that I'm not blocked because I use a vpn service.
there was some kind of attack, but only the the main site is down.
if you wanted the src: https://github.com/itseez/opencv
(win)binaries: http://sourceforge.net/projects/opencvlibrary/?source=directory
QA: http://answers.opencv.org/questions/
DOCS: http://docs.opencv.org/
The site was hacked, and they are trying to restore it (according to Alexander Shishkov).
OpenCV DevZone (code.opencv.org) is still up.
UPDATE: It's now back online.
I have a very basic intranet site for our company, and it's main purpose is to link to SMB shares on our network, so people can open files and edit them, without the need to then reupload to the site.
What I have, is a basic < a href="\IP ADDRESS\SHARENAME\">< /a>
The issue seems to be, regardless of whether I use the IP address, or the actual DNS name of the machine, IE9 always seems to think the intranet is an internet site, and stops these links from working.
Let's say for example, the web server address is 10.1.3.81, and I have a share on that same server for a global phone directory spreadsheet. I want someone to be able to click on the link on the page, and have it open that file directly.
So for the href, I put in \\10.1.3.81\intranet\phone directory\list.xls
Or something like that. IE9 (which is what all our users are using), considers this link to point to file://10.1.3.81/intranet/phone directory/list.xls
That's great, but as it doesnt consider this to be on the intranet, it blocks the file:// protocol, and the link does nothing.
If I add the site to my trusted sites list, it then works correctly. So I am wondering if there is a way on the programming side of things, that will let me create these kind of links and have them auto picked up as an intranet link?
Failing that, I will post on serverfault, and see if someone can guide me on applying a policy to add this site to trusted sites for all users and computers.
Many thanks
Eds
As it turns out, I was accessing the intranet by using either the FQDN or the IP address of the server.
As this article shows, http://support.microsoft.com/kb/303650 , if I just use the server name instead, and drop the domain name from the end, the links behave as I would like.
Sorry for this useless question.
Thanks, Eds