I am trying to use the anonymous meeting provided with in the UCWA sample code. The developer sandbox works fine when I use the metio.net domain but when I try to use my companies domain we get a error message: "Service does not allow a cross domain request from this origin". So when I went to use the Anonymous meeting join and changing the domain with in the AnonMeeting.js to my companies domain I get the same error. I tried the only other option available on the index page, which is My own topology. I used my Skype for business login and gives me the 403 error with the same console message "Service does not allow a cross domain request from this origin". At the company I am at we use Skype for business online.
When we enter the URL http://lyncdiscover.domain.com we get to the xml tree fine but if its https we need to accept the invalid certificate. Once we do this and try to reopen the UCWA sample site we get the same cross domain error.
I would like to know if we can change the url to http within the api. Also assistance in making the anonymous chat work for my domain[or even metio.net] with in the sample code. Thank you anyone for helping me with this
You need to add the location you are hosting your application to the allowed list of your company's SfB servers. I would assume you are hosting your application in localhost. Metio.net is whitelisted for that, hence it works for the metio.net environment.
-- Since I was flagged for pasting the relevant Url link last time with Microsoft published details, I am copying the content from the website ucwa.skype.com --
Allowed Domains
Allowed domains refers to those hosting a UCWA web application.
The samples will indicate that the host domain is not on the allowed list by alerting the following string, sent by the server in the headers of a 403 response:
Service does not allow a cross domain request from this origin.
Viewing the Allowed List
From the Skype for Business Server Management Shell on each server (front end, edge, and director), execute the following command:
Get-CsWebServiceConfiguration | select -ExpandProperty CrossDomainAuthorizationList
Editing the Allowed List
From the Skype for Business Server Management Shell on each server (front end, edge, and director), execute the following commands (replacing the text in {} with your values):
$x = New-CsWebOrigin -Url "https://apps.contoso.com"
Set-CsWebServiceConfiguration -Identity "{YOUR_IDENTITY}" -CrossDomainAuthorizationList #{Add=$x}
If you do not know the value of Identity for your Skype for Business Server, you can run the following command to see all identities configured on the server:
Get-CsWebServiceConfiguration | select identity
Related
I am experimenting with a two-service docker-compose recipe, largely based on
the following GitHub project:
https://github.com/rongfengliang/keycloak-openresty-openidc
After streamlining, my configuration looks something like the following fork
commit:
https://github.com/Tythos/keycloak-openresty-openidc
My current issue is, the authorization endpoint ("../openid-connect/auth") uses
the internal origin ("http://keycloak-svc:"). Obviously, if users are
redirected to this URL, their browsers will need to cite the external origin
("http://localhost:"). I thought the PROXY_ADDRESS_FORWARDING variable for the
Keycloak service would fix this, but I'm wondering if I need to do something
like a rewrite on-the-fly in the nginx/openresty configuration.
To replicate, from project root::
docker-compose build
docker-compose up --force-recreate --remove-orphans
Then browse to "http://localhost:8090" to start the OIDC flow. You can
circumvent the origin issue by, once you encounter the aforementioned origin
issue, by replacing "keycloak-svc" with "localhost", which will forward you to
the correct login interface. Once there, though, you will need to add a user
to proceed. To add a user, browse to "http://localhost:8080" in a separate tab
and follow these steps before returning to the original tab and entering the
credentials:
Under Users > Add user:
username = "testuser"
email = "{{whatever}}"
email verified = ON
Groups > add "restybox-group"
After user created:
Go to "Credentials" tab
Set to "mypassword"
Temporary = OFF
Authorization Servers such as Keycloak have a base / internet URL when running behind a reverse proxy. You don't need to do anything dynamic in the reverse proxy - have a look at the frontend URL configuration.
Out of interest I just answered a similar question here, that may help you to understand the general pattern. Aim for good URLs (not localhost) and a discovery endpoint that returns intermet URLs rather than internal URLs.
I have developed an application that allows MSA (Microsoft Account) authentication. I have registered my app here: https://apps.dev.microsoft.com.
When testing my app locally, I can access my app with no problem at my SSL URL of https://localhost:44300, and MSA works fine. When I registered my app, I used https://localhost:44300/signin-microsoft as the Redirect URI.
Problem: I can also access my app at https://127.0.0.1:44300, as one would expect. However, MSA here doesn't work. The error page says, We're unable to complete your request.
Microsoft account is experiencing technical problems. Please try again later. And the URL of the error page reveals that the error is with a mismatch in the Redirect URI: https://login.live.com/err.srf?lc=1033#error=invalid_request&error_description=The+provided+value+for+the+input+parameter+'redirect_uri'+is+not+valid.+The+expected+value+is+'https://login.live.com/oauth20_desktop.srf'+or+a+URL+which+matches+the+redirect+URI+registered+for+this+client+application.
In the Microsoft Apps page, when I try to update the Redirect URI from https://localhost:44300/signin-microsoft to https://127.0.0.1:44300/signin-microsoft, it doesn't allow me to save my change and it shows me this error: Your URL can't contain a query string or invalid special characters, and it provides a 'Learn More' link: https://learn.microsoft.com/en-us/azure/active-directory/active-directory-v2-limitations#restrictions-on-redirect-uris
After reading the info in this link, I see nowhere that a URI like mine (https://127.0.0.1:44300/signin-microsoft) would be an unacceptable URL, as I'm not breaking any of their rules: I have no invalid characters, no query strings, etc.
My research: Looking online, people are getting the Your URL can't contain a query string or invalid special characters because they are actually using a query string or invalid special characters, such as in this link: https://social.msdn.microsoft.com/Forums/en-US/4f638860-ea57-4f0e-85e0-b28e1e357fe2/office-365-app-authorization-redirect-uri-issue?forum=WindowsAzureAD. I couldn't find a case where someone has entered a valid URI and they weren't allowed to save it.
Why I need 127.0.0.1 to work: I need to expose this website, which is running on my local box. In order to have the website running without having an instance of Visual Studio opened all the time, I'm using csrun to host my website in Azure local fabric (by the way, my app is an Azure Cloud Service, with a ASP.NET MVC 5 app as a web role). I followed this instruction for csrun: http://www.bardev.com/2013/03/12/how-to-deploy-application-to-windows-azure-compute-emulator-with-csrun/. Using csrun, it allowed me to host my website in https://127.0.0.1:444 (but, as with https://127.0.0.1:44300, MSA doesn't work). My end goal is to expose this website with a public URL using ngrok (https://www.sitepoint.com/use-ngrok-test-local-site/), so that anyone can access my site.
Therefore, my main question is: how can I have the Redirect URI be https://127.0.0.1:44300/signin-microsoft instead of https://localhost:44300/signin-microsoft?
Make sure you access this portal through https://identity.microsoft.com as this is the only way the steps below will work.
You can get around this error right now by adding the reply URL through the manifest. Login to the portal, select the app you want to configure, and scroll down and hit the Edit Application Manifest button. Then you can add your https://127.0.0.1:44300/ to the replyUrls field.
There's some funny behavior that will only allow this right now if you only register other localhost reply Urls. If this is the only reply URL you need then it shouldn't be a problem.
I have multiple ASP.NET applications running on a single IIS server like below.
HR app - 223.34.56.32:81
Accounting app - 223.34.56.32:82
CRM app - 223.34.56.32:83
Now, I do not my end users to remember or bookmark all these URLs. Another problem is that these ports (81, 82, 83) are not IANA approved so I do not want to expose them to the end users.
I want to build another routing application (using ASP.NET or nginx), which will do the following
223.34.56.32/HRAdmin.aspx requested - route the request to 223.34.56.32:81/HRAdmin.aspx. End user will see 223.34.56.32/HRAdmin.aspx in his browser
223.34.56.32/CRMHome.aspx requested - route the request to 223.34.56.32:83/CRMHome.aspx. End user will see 223.34.56.32/CRMHome.aspx in his browser
My clients have not agreed to use host headers. I have to make the apps accessible using this ugly looking IP.
I am a noob in this sector. I do not know whether this is actually possible. And what technology can be used to accomplish this?
I set up my own hosted phabricator, everything is working fine (Diffusion repo etc)
I ran into problem after I installed arcanist on my dev box and run 'arc install-certificate', got exception as following:
rying to connect to server...
LOGIN TO PHABRICATOR
Open this page in your browser and login to Phabricator if necessary:
http:///conduit/login/
Then paste the API Token on that page below.
Paste API Token from that page: cli-e644viducdcccrge4i7zo5nfa66d
Usage Exception: The token "cli-e644viducdcccrge4i7zo5nfa66d" is not a valid API Token. The server returned this response when trying to use it as a token: ERR-CONDUIT-CORE: Attempting to access attached data on PhabricatorUser (via getAwayUntil()), but the data is not actually attached. Before accessing attachable data on an object, you must load and attach it.
I am wondering what's might go wrong? Thank you very much for your insights!
I've seen this problem occur many times with our users. In every case so far, the problem has been that users have set up the phabricator uri incorrectly.
Suggestion:
Check your project .arcconfig or your global .arcrc files (if you're doing this outside a project).
Verify that the URI to your Phabricator site is correct. The typical issue I've seen is accessing using http:// rather than https://
We're experiencing some really strange problems with Integrated Windows Authentication with IIS and I'm not sure if I can see a pattern or not.
We have a DNS-Cname record called Fred. We have an IIS website with Fred set as the host header. When I connect to this site I get prompted with a credential challenge. I would expect my credentials to have been passed through. If I enter my credentials I am granted access.
I then create a local host entry called Betty and point the host file to the same IP address as Fred and change the host header to Betty. There is no associated CName record anywhere. When I access Betty I am authenticated automatically and everything is fine.
If I attempt to bypass the CName record and create an entry in the local host file called Fred and change back the host header to Fred. I still receive an authentication challenge.
As I see it have two questions. How is this CName record affecting the resolution here or is it a red herring. Secondly what is happening with this challenge? We have similar symptoms elsewhere and our concern is that our authentication token is getting blatted somewhere. Could someone walkthrough the order in with Authentication occurs i.e. what packets are sent to what machines. Is there a way I can trace this? (I'm thinking WireShark or something similar). How can I prove my authentication token is getting passed and is valid?
The reason for the authentication box is simple: Internet Explorer sends your credentials only if it thinks the host is in the "Local Intranet" zone (default configuration assumed). If a host outside what IE deems to be "local" asks for NTLM credentials, an authentication box will appear, and you have to authenticate manually.
If you want your credentials to be sent automatically, make sure IE thinks it in "Local Intranet". Check the zone info far right on the status bar to see the currently active zone.
IE takes into account multiple things in order to decide whether a host is to be considered as "Local Intranet":
is it an IP address in the local sub-net -> YES
is it a simple host name (i.e. "no dots") -> YES
in the IE options: is it in the "Sites..." list for "Local Intranet" -> YES
in the IE options: is it in the proxy exclusion list -> YES
is it an UNC path -> YES
otherwise: NO
Sometimes, an old password exists in the personal passwords list for that host name (accessible through Control Panel -> User Accounts). If it is wrong, similar issues can occur.
My suspicion is that your host "fred" does not fulfill conditions #2 through #4, but your test case "Betty" somehow does.
What way the name was resolved (CName record, A record, hosts file, other) makes no difference, because the method of name resolution is opaque to the calling application. IE just asks for name "XYZ" and gets an IP address back.
Recent configuration changes can require you to clear the local DNS cache, though. An occasional ipconfig /flushdns would help here, alternatively you can stop the DNS Client service for a while.
The described internal logic is applied to the host name and security settings change based on the outcome.
CName would be a red herring. Has no effect on Windows Auth or not.
The easiest way to trace it is with fiddler. You should see your request followed by a 401 response (it contains the authentication the server supports), then your request again is sent with the authentication details (or you are prompted and then it's sent)