Our customers(at least two from different regions) have reported an issue with access to SharePoint sites which contain spaces in URL. After open some sites in new tab, they get
After some investigation we have found that SharePoint sites register Service Worker in browser.
The Service Worker intercepts all requests going from current page, apply some logic and one of the branch in the logic leads to the error.
Let me explain what happens:
When you have custom home page on a site, and you navigate to the root site URL like https://tenant.sharepoint.com/sites/mysite, SharePoint will automatically redirect you to the custom home page like https://tenant.sharepoint.com/sites/mysite/SitePages/MyCustomHP.aspx
All these requests are handled by the Service Worker and it treats this redirect as a trigger for re-authentication and sends you to Authenticate.aspx
In order, Authenticate.aspx works incorrectly:
Steps to reproduce:
Open any modern team site(in Edge or Chrome, I tried in Edge)
(like https://tenant.sharepoint.com/sites/my-team)
Create a modern subsite with spaces and navigate to it.
(for example https://tenant.sharepoint.com/sites/my-team/Site with spaces)
Open Pages library on the subsite and create custom Site Page
Make it as Home page
Open new tab and paste the URL [https://tenant.sharepoint.com/sites/Site with spaces]
The Result you can see above. Hmmm... can't reach this page
Questions:
Why does Authenticate.aspx works incorrectly ?
May be the logic in Service Worker is wrong? and such kind of redirects should not lead re-authentication or it should encode parameters to Authenticate.aspx by other way?
When will it be fixed :) ?
Possible Workarounds
Clear IndexedDB/Route.Config in dev tools and restart Service Worker
Change the URL and remove spaces
Microsoft has fixed their code of Service Worker in 2021-08-27 release
Now, the previously buggy code, looks like:
As you can see double encoding check was added
How it looked before you can check above.
Related
So, I am trying to implement a SharePoint intranet site for an organization. However, there is one application in particular that they would like a link to on the homepage. Unfortunately this application can only be used via the IE tab google chrome extension (I know, dumb) but app devs have yet to add chromium compatibility.
Any way the link looks like this:
chrome-extension:
//hehijbfgiekmjfkfjpbkbammjbdenadd/nhc.htm#url=https://website.com/sub/sub.Hub.aspx
But share point requires a https:// on the beginning of a link.
If you throw that destination into chrome directly it navigates fine, but if you add say https://google.com/ on the front or https://*/ it doesn't work.
Is there a syntax that will allow me to put https:// on the front of this without getting a 404 error?
Never mind, I ended up re-directing this through IIS internally
I am working on SharePoint Online site collection and suddenly Site Contents _layouts/viewlsts.aspx stopped working and showing the message
This page isn’t working - If the problem continues, contact the site owner. HTTP ERROR 401
I am the site collection administrator on this site, so this is not a permission related issue. Also, checked on multiple browsers and with different users and all are facing the same issue. Also, Console logs are not showing any error messages.
Scenario - I just ran a PnP PowerShell command to create lists (list provisioning) and after that Site Contents were not working, however the same command I executed few days back and everything was working fine.
My application custom pages / site settings and all the lists & libraries are working fine (when accessed directly from URL), only Site Contents is not working.
Clear the browser cache and open the site in an incognito window to check the result.
Go to Site Content and Structure page as site collection administrator, delete the provisioned list to compare the result.
_layouts/15/sitemanager.aspx
If the issue still exists, raise a new service request to Microsoft to check if there is something wrong on back-end side.
First off, apologies for not knowing the nomenclature for what I'm looking for, I'm not typically a Windows web admin.
I have a SharePoint website which contains several subsites. We also have several alternate URLs that point to specific pages, and some of those alternate URLs have friendly URLs which also redirect to other specific pages. We're in the process of migrating from a SharePoint 2007 site to this one, and in the process, I'm trying to remove our reliance on our registrar for handling some of this redirection, because it is apparently not a free service.
Currently our registrar does the following redirects:
http://alias1.tld/* redirects to http://subsite1.ca/page1
http://alias1.tld/friendly redirects to http://subsite1.ca/page2
http://alias2.tld/ redirects to http://subsite1.ca/page3
I know I can accomplish the first and second by setting the sites up in IIS, and using the HTTP Redirect function, but I'm not sure how I can do the second one. In Apache this would be easy, but I'm not sure what I'm looking for here.
Is this something that should be handled within SharePoint, and have that take care of redirecting alias1.tld/friendly to the specific page, or is this something I need to setup in IIS? Is this what URL rewrite is for, or is there a different IIS way to do this?
I'm not sure that this is the best way to do it, but I got things working how I wanted them. Here's what I ended up doing:
Create a new subsite on subsite1 to give me the URL subsite1.ca/subsubsite
Create a redirect from alias1.tld to subsite1.ca/subsite
Create 2 pages for the new subsite. One for the default page and one to use to redirect to page2. Both pages are redirects, Default points to Page1, the second points to Page2.
Set the subsite to use Managed Navigation for global and current through Site Settings > Navigation, and created a default term set by selecting the new subsite in the list and then clicking Create Term Set, then clicking OK.
Then created a term store for the one page that needs to be handled differently by going to Site Settings > Term Store Management. Click on the Term Set created in the last step, then select New Term. On the Term-Driven Pages tab, create the friendly URL and then select the target page, which is the redirect page created in step 3, then click Save.
I'm having quite a hard time figuring out this problem and I need your help. Here's the scenario:
I have a sharepoint 2010 web application on my port 80. This has 2 site collections, the root, and the /sites/official. My problem is: The root site is empty, but in the future it will be my something (I don't know what yet), but my other site collection is ready to go and I already have an Internet address for it.
What I want to do is configure everything in way that I can type http://contoso.com and get as response my sub-site (yes, its a kind of redirect)...
how can I do it? What and where should I configure it?
add content editor webpart on your root site collection and put this javascript in that webpart
<script type="text/javascript">
window.location = "http://contoso.com/sites/official"
</script>
Open IIS manager
Right click on your SharePoint website -> Properties
Go to tab Home Directory
Choose A redirection to a URL
fill the URL for redirection. for example: http://contoso.com/sites/official
Notes:
Make sure to check A Directory below URL entered to avoid redirect loop
Link to another thread might interest the reader - immediate redirect page in sharepoint
Screenshot:
Add alternate access mapping for the sub-site collection from the central administration.
Central Administration > Application Management > Web Applications > Configure alternate access mappings
I have a WSS 3.0 system using SSL where every page is supposed to be served as https. Almost all pages do come out as https, but in certain cases I click on a link and that brings up an http version of a page (which does not load). In those cases I have to put the 's' in by hand to get the page to load. Places where this happens are:
/_layouts/newgrp.aspx : when I try to create a new group, it takes me to http://server/_layouts/newgroup.aspx, although it should be https. The page does not load at http. It does load if I change the url by hand.
/_layouts/edtgrp.aspx : same thing as newgrp.aspx
if I go into a document library and view version history for a file, the URLs to the individual versions of that file are http. Interestingly, the browser status bar also indicates http when I hover over them (so it seems that SharePoint gets confused when it generates the links, rather than when I click on them)
To fix this, I have tried adding some javascript to the DOM that searches for instances of http and replaces them with https. This works in some cases, but there are some places where javascript can't reach, for example when SharePoint provides the target URL in response to a POST request, which I think is the case with newgrp/edtgrp.aspx.
I have also tried adding ISAPI filters to redirect pages from http to https. This seems to cause redirect loops, and in any case I'm not sure if such filters would preserve querystring or POST information.
Has anyone seen this problem?
Update: We have switched to ISA from Squid, and the problem continues in the version history, but not on new group or edit group. We have not seen any improvement yet from changing AAM settings.
Places where this is happening in ISA:
"Version History" under item in list or document library
"Manage Permissions" under item in list or document library
"Alert Me" under item in list or document library
"Add Users" menuitem in "People and Groups" page
"Group Settings" menuitem in "People and Groups" page
"Edit Group Quick Launch" menuitem in "People and Groups" page
"Set Up Groups" menuitem in "People and Groups" page
"List Settings" menuitem in "People and Groups" page
Not sure if this is it, but have you checked your alternate access mappings to make sure they say https instead of http?
I would echo the suggestion to check your Alternate Access Mappings. Is the SSL being done on the SharePoint Front Ends, or is it being done via a piece of dedicated SSL hardware?
Use an HTTP Module to modify SharePoint's output so that links are always changed to https. Such a module can plug into IIS and modify the HTML of anything rendered. I've used this technique to make SharePoint XHTML compliant and it works well.
Even better, almost all of the work has already been done for you. The UrlRewritingNet module is open source and available for free download. It should work fine for your SharePoint site. This tool has great documentation and uses regular expressions to match which URLs to alter. It should be pretty easy to write one for your case, e.g. ^http://. There's also many more advanced options you can take advantage of if necessary.
If you'd prefer to write your own then there is a good article called Rewrite.NET -- A URL Rewriting Engine for .NET on the 15 Seconds site.
Finally, if you're using IIS 7 you could try its URL Rewrite Module. I've never used this myself and don't know if it works with SharePoint, but it's the most UI-driven solution available.
Add a redirect in IIS from http to https. Every time you access that page it will redirect you to your https page instead.
I would also suggest placing WSS on another server to see if you have the same problems. If you don't, you might need to rebuild/migrate your stuff over.
Alex answered this question with an approach that I think will generally work. Here is how I fixed this specifically.
It looks like when a SharePoint aspx page is loaded, it populates a javascript structure of type ContextInfo (defined in init.js), which is instantiated in the variable ctx. That structure has a member called httpRoot, which is later used in core.js to build menuitems in various dropdown.
This ctx.httpRoot is for some reason populated in javascript in the aspx files created by SharePoint with a line like this:
ctx.HttpRoot = "http:\u002f\u002fsubdomain.domain.com";
Yes, it has Unicode slashes and it has http instead of https. I have no idea why. But, fixing this line of javascript seems to fix the problem.
I changed the line by adding a URL translation rule in ISA that converts http:\u002f\u002f\ to https:\u002f\u002f\ . I suspect that an HTTP module that makes the same replacement would also work. Or possibly some well placed javascript that reassigns the variable at some point.
I still believe this is not ideal and there must be a more appropriate way to fix these links.