I am using approved client id with test_mode:false, in api, an opening the template in mobile app. the domain registered in client id is same from which i am sending the template .
Error-->
Domain mismatch for client ---. This page can only be viewed from ---, unless the signature request is a test and "skipDomainVerification" is set to true in the HelloSign Embedded "open()" method. See the documentation for more info.
I'm hoping that since then your issue has been solved. A "Domain mismatch" error means that you are loading HelloSign iFrame outside of the approved domain for this specific app.
If you are going to load the iFrame on another domain that does not belong to your approved domain for testing purposes, add the test_mode parameter in the API backend call and "skipDomainVerification" is set to true in the HelloSign Embedded "open()" method. You will be able to load the iFrame on your local machine or any other domains.
Related
I'm trying to have a solution where one web application is serving multiple domains, for each domain I would like to configure its own providers, using the app id and secret for the external provider, I would like the cookie domain and the providers information to be read from a database based on the current domain name, so for example:
switch (currentDomainName)
{
case "web1.com": load cookie domain and providers information for web1.com ...
case "web2.com": load cookie domain and providers information for web2.com ...
...
}
I'm facing two major problems:
I have no HttpContext available at the Owin Startup ConfigureAuth() and I'm not sure how to determine which domain name is used early on Startup...
I understand that Startup only run once per web application, so for example, after web1.com is accessed for the first time, ConfigureAuth() will not run again for web2.com once it is already set by web1.com
I wonder if I can override some Owin methods and make it non static... or maybe find a way to implement this in a different way (but I still like to use Owin)
Where do I start?
You can get the request url and then do a lookup in the database to see what is the domain related customer. There could be a table that lists the identity providers for this domain
Example
TenantDomains
*************
TenantId URL ......
tenant1 https://tenant1.company.com
tenant2 https://tenant2.company.com
IdProviders
***********
TenantId ProviderIds ......
tenant1 Custom, Social
tenant2 Social
Here the names are used instead of identifiers for ease of readability. However, the approach still remains the same.
You could do all the above lookup in a middleware and then use the value in the Environment and then set up the pipeline based on the data or decisions made earlier.
Example:
You can access the incoming request from the OWIN Context and do all the operation that would do otherwise on a HttpRequest from the owin context's request itself.
app.MapWhen(req => req.Request.Headers.ContainsKey("Authorization"), apiAuth =>
{
// do anything that matches this request
apiAuth.UseBearerAuthentication(new BearerAuthenticationOptions());
});
HTH
I have Application Insights configured on both the front and back-end of my website, which operate on different sub-domains (let's say www.mydomain.com and api.mydomain.com).
The cookie containing the user information set by setAuthenticatedUserContext is stored by AI with the cookie domain set to www.mydomain.com. When I make a call to api.mydomain.com the cookie is not included, and therefore the credentials I set are not associated with any AI data logged by the API.
My API has Access-Control-Allow-Credentials set to true, and the front-end has withCreditials set to true on the XHR object.
Can I get AI to set a different cookie domain, or is there some other issue at play here stopping the user information reaching the API?
Update: I notice Google Analytics sets a cookie with the domain set simply to .mydomain.com, and this cookie information is included with calls to my API.
This is not currently supported but there is an issue opened on GH for it: https://github.com/Microsoft/ApplicationInsights-JS/issues/64
Please continue monitoring GH link, we will provide an update soon. Thanks!
How can I setup PAW to work with Facebook locally for development? Or even at all for that matter?
I have a node.js backend that I'm setting up with Facebook Auth. Every one of my routes needs the user to be logged in. I have two endpoints related to FB Auth. localhost:3000/api/v1/loginFB and localhost:3000/api/v1/callbackFB. Both of these work great in a web browser.
loginFB simply returns this string... https://www.facebook.com/dialog/oauth?client_id=523534457345&redirect_uri=https://localhost:3000/api/v1/callbackFB&scope=email,public_profile,user_friends.
When I call that URI in a browser, it returns a code=blahblah which my callbackFB endpoint uses to fire off another request to get the access token. All good.
So now in PAW I'm confused by the difference between the request URI and the Authorization URL text field? Should I use the loginFB URI for my request URI? And then https://www.facebook.com/dialog/oauth in the Authorization URL textfield?
Basically what's happening is that when I click Get Access Token, it returns the code but my callbackFB endpoint 500's by saying "This authorization code has been used." The code that it's getting returned is definitely different each time I Get Access Token.
This is where I'm at with this thing (Client ID and Client Secret are actually my App ID and App Secret from fb's dev management site, and the Access Token URL is actually set to https://graph.facebook.com/v2.3/oauth/access_token which I'm 99% sure is the correct URI):
This is the error I get when I click Get Access Token button:
It would be awesome to get some advice from anyone with experience with this issue. Thanks.
Re: #MichaMazaheri
tl;dr Fixed in version 2.2.2
Sorry for the super late follow-up. We actually fix this exact issue in Paw 2.2.2, which is already released on our website, and pending review for the Mac App Store. (It was some JSON vs. Form URL-Encoded parsing issue). Thanks for reporting.
I have a Silverlight 5 app that runs on a SharePoint 2007 site. The Silverlight app gets a bunch of data from SharePoint lists using the Lists.asmx service. The main site is secured using NTLM security and Silverlight is able to successfully call the web services without having to eplicitly set anything to do with authentication. We extended the SharePoint site to a second domain that uses asp.net FormsBasedAuthentication. On this version of the site, the first web service call fails with a 403 Forbidden response and the exception:
System.ServiceModel.CommunicationException: The remote server returned an error: NotFound. ---> System.Net.WebException: The remote server returned an error: NotFound. ---> System.Net.WebException: The remote server returned an error: NotFound.
As I understand it, this is a generic message and not the true exception. Well, obviously we need the real exception to have any idea what the problem is. This MSDN page (Creating and Handling Faults in Silverlight) offers two solutions to getting the real exception.
The first is to modify your WCF service to return an alternate HTTP status code. This doesn't work because for one, it is not a WCF service, it's an .asmx web service so I can't add the suggested WCF behavior to modify the status code. Second, it's SharePoint's service so I can't do much to modify it anyway. Could I modify IIS to achieve an equivalent solution somehow?
The second solution is to register an alternative HTTP stack in the Silverlight application. I tried this out and found out the "real" exception was an authentication exception. So I went down dead ends trying to figure out out to get authenticated for about 24 hours only to finally find out that normally, the ASP.NET authentication cookie is passed with the service request, unless you are using the Client HTTP stack. So registering the client HTTP stack allowed me to see real exceptions, but it created its own exception which seems to only be fixed by not using the Client HTTP stack...
I believe have verified with Fiddler that the authentication cookie is being sent when using the default HTTP stack. I don't know if the Lists.asmx service is unable to use it and is giving an authentication error anyway, or if there is some other exception. How can I determine the cause of the "The remote server returned an error: NotFound." exception?
Well, this isn't a good answer to the quesion "How can I determine the cause..." but it's what worked for me. What I did was open up STSSOAP.dll, the assembly containing the Lists service implemention, in reflector. I copied the relevant code to implment my own GetListItems method in my own service. Luckily, the actual Lists.GetListItems method code was minimal and just called other SharePoint methods and even luckier, those methods & members are all declared public so I was able to do this. I then replaced Lists.asmx with my version on the server and attached the debugger to get some info. What I found was my authentication cookie was being used and HttpContext.Current.Session.User.Identity.IsAuthenticated was true. So it knew I was logged in. But I was still getting an authentication error which I could see farther down in SharePoint's code, was converted to a 403.
So I know asp.net considers me authenticated but SharePoint says I don't have permissions. But the service account the app pool is running under is a SP admin so why don't I have permissions? So next I inspected the SPContext.Current.Web.User; SharePoint's current user. It was null! In other words, as far as SharePoint is concerned, I'm still logged in as an anonymous user because I haven't explicitly logged in with a domain user, and an anonymous user doesn't have permissions on the list I'm accessing or most of the rest of the API. The answer by Sean McDonough to this quesion lays it out.
Basically I need to run the involved code with elevated privileges to get the code to run under the asp.net service account that I originally thought it was running under. If using the API, you can use the RunWithElevatedPrivileges delegate. But if you're calling the web services, you can't do that. The few options I could think of were:
Call the services on the base site that uses Windows Authentication. This would require me to embed the credentials in the client-side Silverlight application which is a security threat so I nixed this one.
Implement my own web service to get the data for me.
The web service could access the list using the SharePoint API and
RunWithElevatedPrivileges.
The web service could call the Windows Authentication site's services passing the current credentials or other embedded credentials.
For implementation ease, all I've done so far is the second option under number 2 and it's working. However, it is clunky and I may change to option 1 which I expect will also work.
I'm developing a Django application. I need to authenticate users using Facebook and get the user's friends list to invite them to my site. To do this my application has to be registered with Facebook to get the API key. In the process of doing so I'm struck with the list of settings.
"http://localhost/login" --> this is the login page in my application where I have the Facebook-connect button
I need Facebook to redirect the response to "http://localhost/result", where I have a view to parse the result.
Please let me know how to configure Facebook.
Facebook can't redirect the response to 'localhost', as that's obviously local to your machine, hence the name. Your app needs to be somewhere Facebook's servers can actually see it - ie on a public host somewhere.
In other words, you can't develop and test a Facebook app completely on your local machine, as you would with a normal Django app. You'll need to upload it to your host at regular intervals to see any changes.
Alternately, you can set up port forwarding on your firewall/router to allow Facebook to retrieve directly from your localhost. The instructions for doing this vary greatly between different firewall/router manufacturers. What you need to do is open external port 80 and forward it to port 80 (or whatever port you have your HTTP server listening on) on the host machine where your app is, find your public IP address, and then use them as your callback address as follows:
http://<your.ip.here>:80/login
This will allow you to test your FB or FB-Connect app on localhost.