I have a Xamarin.Forms mobile application that connects with a soap web service. The same domain hosts multiple web apps. I need to update the domain with SSL, but I do not want any downtime in the application.
My first thought was to check see if the https url responds and if not to check for http.
How can I check the protocol of the domain from a mobile app? Is there any better idea to accomplish this with no downtime?
More Info: The solution I am proposing is only so that there is no downtime while the application passes review in the Appstore and Google play. After that I will release a second update to allow https only. I need to have no downtime in the applications using the API while the transition happens. I am not saying that this is a permanent solution or a good practice.
Related
We are developing asp.net core applications that will require sending emails with gmail among other providers (client accounts). This applications will not be hosted by us but by many of our clients.
The application may be hosted on their domain or no domain at all (IP address only).
I am struggling with which authorization process I should use since I can not use the Javascript client or any redirect URI method due to unknown origin/domain. I also can not use localhost origin since there is no way for me to start a local http server from a browser. Programmatic extraction is deprecated. The only thing I am left with is manual copy/paste but apart from it being very user unfriendly Google documentation states that that might be deprecated in the future as well.
Am I missing something?
Please point me in the right direction as to how I should proceed.
I'm working with a Point of Sale computer that is exporting a CSV file. I want to parse that file of inventory items. I want to download the product (search by SKU), update it with whatever is in the Point of Sale system, then send the updated product back to BigCommerce's API.
It seems like the whole API framework is designed around "apps" that end up in their appstore, of which this isn't the case at all.
I want to install a small .exe on a retail Point of Sale system that does an API call, not turn it into a web server and have to put SSL on it.
Is there a more straight forward way to work with the BigCommerce API then their "app store" route?
More digging around, I came back to this. So you really can't have any code running that isn't on a publicly available web server, even when you're developing? That can't be right.
To integrate with our single sign-on flow, your app must be a publicly
accessible web application. Choose your preferred language, framework
and hosting solution, and go from there.
If you do not want to set up an "app" using OAuth and an SSL certificate for your code you can use the Basic Authentication method for now. Note that this is deprecated and I do not know when exactly they will discontinue this method of authentication. If not wanting to go with SSL and an app at this point that is your best option.
Otherwise you can look at a self-signed SSL certificate if the app is just for your own code but this would again require setting up an app.
I faced a similar situation as yours. You can implement a oauth2 callback by setting up a SSL site on your machine using a self signed cert, say on port 8000. Then, while using the store owner creds 'install' your app from the my apps dashboard to obtain your token.
This is all assuming you've setup a page to handle the callback request and exchange the temporary token for your permanent one.
It's a bit painful starting out but once you get going its not so bad. I did everything in .NET.
Based on my discussion with their API team I wouldn't waste time with basic authentication if you're just starting out since you'll have to convert sooner than later anyways.
You definitely don't need a public SSL callback URL though if you aren't looking to create an app for their marketplace.
Hope this is of some help.
We made a CMS that allows users to connect to Google Analytics via a connector. I'm in the process of porting this connector to OAuth2 and am wondering what kind of application I need to register.
The issue is that the CMS is installed by our clients at arbitrary URL so we don't know the complete set of redirect URLs that I would need to register a Web Server application. Google's OAuth won't let me redirect to an arbitrary URL that I pass in during the authorization request?
Would registering an installed application and then using the urn:ietf:wg:oauth:2.0:oob special redirect URI be best? Seems like this allows the user copy/paste their authorization code from the browser back into our application.
Thanks in advance!
Indeed the installed application will allow users to copy and paste and not register. This is appropriate if the clients are end users of your application, and not say, configuring it as a plugin which will then provide web services to the client's users (where such users will then be prompted via the OAuth2 consent dialog). In the latter case you probably want to ask your clients to register their own web site as web application with Google and use a configuration tool for your CMS application to set the client's redirect URLs.
Why the distinction? Because in the first case the consent action is about your relationship with your clients, but in the latter case it expresses trust between your clients and their users. For instance, you don't want your CMS application to be disabled for abuse because one of your clients has misbehaved, as it'd affect all your clients. However, if you intermediated the consent you made it difficult for Google to understand the distinction.
I'm trying to construct a webapp to add events to an employee's google calendar and would like to use OAuth for authentication.
However, my webapp is forced to be on an intranet behind a firewall; the server has outbound internet access, but blocks in-bound access if you aren't on the intranet or VPNing into the intranet.
I'm reading up on OAuth, but can't figure out if part of the authentication-handshaking process would be blocked by my firewall. (And I'd like to know if its possible before spending time to implement if it isn't possible; and know so if I run into errors I can debug them).
To expand on planetjones's answer, as long as google can resolve the DNS for your application url oauth2 should work behind a fire wall. We had some issues getting getting oauth2 working behind our firewall because we were trying to use a non fully qualified domain name.
OAuth should work just fine over http, using POSTs and GETs and if your client can set the Authorizatioon header. The client should create all the requests and as long as it follows redirects this should be ok - there's never (to my knowledge) a case where an external server initiates an inbound connection.
For added confidence try OAuth with an existing third party service from behind your firewall to be sure. This looks like a good starting point and this is the definitive guide for following the flows of an OAuth call.
We are developing an app that consists of a web server that hosts a web service (amongst other things) and a client that will be communicating with that web service. Both the client app and the server are expected to be used within a corporate firewall. This application will be packaged up and deployed to organizations across the world—so it needs to be flexible enough to work in multiple types of environments.
My question revolves around web service authentication and what is appropriate for real world scenarios. I know some companies have proxy servers that require a separate authentication. How often is this a requirement across organizations? When does the proxy server force the user to authenticate (can you access internal sites without authenticating.. is the authentication for only external sites)?
Reason I ask these questions, is I’m not sure what kind of capability we should build into our client application for authentication to the web service. By default, we are taking the current user credentials and passing that up to the server. Do you think this is sufficient? In a case where a company will require some form of alternate authentication for internal access, this will not work. My question revolves around this last case—how often does it happen? Why would a company force alternate credentials for internal access?
Thanks!
Why not make it configurable? Further, use WCF and you have the ability to configure just about anything you might need, in most cases without changing your code.
If Internet Explorer can reach a site through the proxy server without prompting the user, your call to the web service should "just work". If the user is prompted by IE, you'll need to put together a way to fill in the proxy server authentication information.
I've run into quite a few problems getting web services rock solid, but never had a proxy server authentication issue.