2 weeks ago an authorization on all my sites stopped working. There is no record on log file. Looks like a page is just refreshing, but there is no access. Previously, everything worked fine.
There alco a console message:
This page includes a password or credit card input in a non-secure
context. A warning has been added to the URL bar.
In this time there is an access to CMS site's administration application
Options:
Reset all browser cache
Try in different browsers (FF, IE and etc)
Write the authorization script using the API and run it at the root.
Related
Created a simple PWA, made the manifest file and service worker and it works great in Chrome on my iMac. Looking at the console, I can see that the service worker is registered and running and it recognizes the manifest file. Simulate network loss and it still runs just fine like it's supposed to. All good, right?
When I serve it from an HTTPS it opens in the browser on the phone just fine and adds to the home screen just as it should but when I try to run it from the icon on the home screen, all I get is a blank white screen.
If I delete the icon and then serve it from an HTTP connection and save it to the home screen, it does everything just as it should, runs from the icon you place on the home screen (when done from http) but of course won't run offline.
What am I doing wrong? Not even sure where to start looking!
the problem could be the CROS access origin for HTTPS requests between your PWA and your API server . had the same issue with my PWA. it worked fine in chrome or desktop and run fine the first time I was opening it in mobile chrome but when the services worker get registered it return CROS access origin.
to debug this problem I recommend using chrome inspect on your mobile device.
you can find the guide here
check
Access-Control-Allow-Origin
between API and PWA servers.
you must allow your PWA URL to access to API server . you can either use the PWA URL or * to access all URLs.
check
Access-Control-Allow-Headers
in your API server.
if you are sending authentication or cache-control header with your requests you must add them to Access-Control-Allow-Headers.
and your PWA and API URL must have a valid SSL certificate.
also, check start_url in manifest.json
you have to set the full URL including protocol in start_url, index.html is not necessary.
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.
I have a simple Intranet Website that is just a few HTML pages with a little JavaScript and CSS.
If Allow Anonymous is ON, everyone can see it. It works.
In IIS, I turn on Basic Authentication and it only partially works as expected.
The company only allows IE and Edge installed on Windows 10 PCs for now.
Specific users have been added to that server running IIS.
In IE when users go to the website now, they are prompted for their username and password. Then the website loads.
However, in Edge, the users are never prompted for the their username and password. A 401 errors loads instead.
I have already tried putting the username and password in the URL like so: https://username:password#URL but that did not work.
I want the same or similar behavior that works in IE for Edge.
I assume you're using Edge Chromium browser, correct me if I'm wrong. The issue might be related with this policy: AuthSchemes.
You can visit edge://policy in Edge and check if it has an AuthSchemes policy set. The policy can be used to disable Basic Authentication. If your browser has this policy set, you need to enable 'basic' value in the policy.
I don't have this policy set and I visit the test page https://jigsaw.w3.org/HTTP/Basic/, the Basic Authentication works well in Edge.
You can also refer to this thread and this thread which have similar issues.
I have a checkout page written in PHP that uses affiliate tracking.
Many affiliates like to advertise via Instagram.
When using the Instagram In App Browser on mobile phones anything within the code that relies on the $_GET variable is failing as it never seems to have any available data.
Thoroughly tested and issue is specifically with the Instagram browser, Facebook browser works as expected.
I can detect the Instagram browser ok via User Agent to do a bit of damage control but don't have a full working solution.
I attempted to force my page open in native browsers on the phone but couldn't get it to work, it was just refreshing the page In-App.
I've attempted loading scripts in iFrames to get needed data but those seem to be blocked as well when going through the In App Browser.
Open to any suggestions.
This resolved the issue for me.
WP Engine host Redirecting Bots
WooCommerce Checkout Issue specific to Instagram In-App Browser
I'm the IIS admin, not the developer on this site, so the code is opaque to me. I'm stumped, though, for where to look.
Using Windows Forms Authentication, the user is directed to a login page. If their password is expired, they are directed to ChgExpiredPwd.aspx. On our dev and test servers this works. On our production server, the user is redirected to login page again with a "ReturnURL=ChgExpiredPwd.aspx". Not the desired behaviour.
Fiddler says the server is responding with an immediate 302 redirect to the login page. The test server responds with a 200. The IIS properties for the site and for that page have no redirects - all, "The designated file." There's no redirect built into the codebehind so's I can see it. No redirects in the target page, though the redirect is happening server-side, so it has to be in the code somewhere. If I take \bin*.dll from production and put it all on test, it does not reproduce the error.
I'm out of ideas.
Have a look in the web.config file at the root of the site. Forms based authentication is typically configured there and the default behavior is to redirect from a "secure" page to the login to authenticate (if the user has not yet done so), and one of the parameters it passes is the ReturnURL.
This explains it pretty well: http://msdn.microsoft.com/en-us/library/aa480476.aspx