My typical workflow is that I develop on localhost, but with Google Apps Marketplace this hasn't been possible. OpenID works fine, but access to Data APIs via Oauth results in errors.
Token invalid - Invalid token: ACL not found for domain: 358xxxxxxxxx and consumer: 736xxxxxxxxx
Currently I have been using the following workflow, but it is very tiresome.
local develop » local push to github » remote pull from github » remote test » repeat
Is there a way to develop locally or another suggested workflow?
Solution:
A mashup of #koma and #JTeagle suggestions, I have multiple branches with Oauth keys in each config respective of the branch. I also created a unique localhost domain my_project.dev which satisfies Google's requirements (since their localhost trigger wasn't working for me)
I am not sure what github as to do with it, but if I understand well, it is difficult to do OAUTH on localhost. That is indeed cumbersome.
My solution for this problem is to register my dynamic DNS domainname in the Google Api Console and then do port forwarding on the router to my development machine.
This way, your development environment can do all the OAUTH requests and the callbacks from Google hit the router, and I can debug them.
Related
I am trying to use the snowflake connector inside docker container. I want to use the externalbrowser authenticator so that I can make connection using Okta credentials but the connector is failing with below mentioned error.
DatabaseError: (snowflake.connector.errors.DatabaseError) 250008 (08001): None: Failed to connect to DB: xx.snowflakecomputing.com:443, Unable to open a browser in this environment.
(Background on this error at: http://sqlalche.me/e/13/4xp6)
As an aside, I'd recommend removing your account name from the question (shown in the error).
You are correct that the "externalbrowser" option is a browser-based SSO. It might be possible to get this running a docker container with some extended software and configuration, but I wouldn't recommend it as it doesn't seem worth the effort.
Instead, there's alternative SSO authentication methods you can look at such as Native SSO Okta, key-pair authentication, or external OAuth. These won't require the browser.
Our OPS team have configured a SSO tile that connects to ADFS. I am building a sample application that utilize an SSO service instance. I can deploy my application to PCF and remote debug my SSO configuration. These things work.
What I need is a way to access the SSO service instance while I am developing on my PC. Otherwise only way to verify my code really works is to deploy my application to PCF and either add log statements or configure remote debugging. Both of these are pretty time consuming.
I looked into configuring ssh access to pivotal services. That works for database service instances, but not for SSO service instance. Has anyone figured it out?
After repeated trials and error, I found the solution. Posting it here in case someone else has similar issue
In PCF, for your SSO add a new application. Auth redirect url for this application should point to your localhost. In my case it is http://localhost:8080
run cf env . Copy the p-identity section only and save to vcap_services.json. Then update the clientId and clientSecret with the values from the new application created in previous step.
Use the following command to start your application
VCAP_APPLICATION=true VCAP_SERVICES=$(cat vcap_services.json) SPRING_PROFILES_ACTIVE=... ./gradlew bootRun
How can I use Stackexchange API when it does not support localhost or any dev URL with port number?
It is very difficult to push code to Heroku as it was suggested in one answer on StackOverflow during development as it slows down development work.
I have registered my application with the API but I cannot specify port number there and therefore I cannot implement the functionality of importing user data into my Rails app.
Install ngrok locally . Start the ngrok server & use its url. See ngrok(https://ngrok.com) for more details
I have used Bitnami VM to deploy Parse Server on Azure but I cannot seem to be able to access Parse Server Dashboard. What URL is it available on? Do I need to open any ports?
Just an update on this. A new version of Parse Server provided by Bitnami is now available in the Azure Marketplace. The new version does include the Dashboard.
Have you been following Bitnami instructions?
It states you can access the dashboard using this URL: http://[server-IP-address]/parse
This means only TCP/80 port needs to be open (on your Network Security Group if you use one or in your VM ACL if you don't).
You have now other (probably easier) options to deploy Parse Server on Azure:
using a dedicated ARM template leveraging Azure services (App Service, DocumentDB, Notification hub, ...).
using Azure App Service with the original Facebook/Parse version with MongoDB.
I've got it. The bitnami guys were kind enough to reply to me for this topic:
You can launch the latest Parse version that ships the Dashboard from https://vmdepot.msopentech.com/Vhd/Show?vhdId=64574&version=66817 It could take some time to be available in the Azure Marketplace
So bottom line, use the image from VM depot and not the one on Azure Marketplace as it is an old one and doesn't include the Dashboard.
We want to migrate our custom steps from XAML build to new build task in TFS2015 on-premise. I installed NodeJS and tfx-cli but when tfx-cli want to connect to TFS I need to provide pat (personal access token) but I cannot find where I can get it. All samples is for VSO but not for on-premise TFS2015. Is it possible to get PAT from on-premise TFS2015?
TFS 2015 doesn't support Personal Access Tokens, this feature was introduced with TFS 2017. In the mean time you'll either need to configure basic auth and use that (only enable basic auth if your TFS server is running over SSL), Or use the trick below to trick the command lien tools to authenticate by lettign an NTLM proxy (like Fiddler) handle the auth for you.
If you do not want to configure Basic Authentication on your TFS server (which many people don't want due to security concerns), then you can use a neat trick to let Fiddler handle your authentication:
Then enter:
C:\>set http_proxy=http://localhost:8888
C:\>tfx login --auth-type basic --service-url http://jessehouwing:8080/tfs/DefaultCollection
You'll be prompted for a username and a password, it doesn't really matter what you enter, fiddler will handle the authentication for you in the background:
More detailed steps outlined on my blog.
If you're battling self-signed certificates, which is also a common problem when using tfx against a on-premise TFS server, make sure you're using a recent enough version of Node and point it to an aditional cert store using environment variables:
As of Node.js 7.3.0 (and the LTS versions 6.10.0 and 4.8.0) it is now possible to add extra well-known certificates to Node.js with an environment variable. This can be useful in cloud or other deployment environments to add trusted certificates as a matter of policy (as opposed to explicit coding), or on personal machines, for example, to add the CAs for proxy servers.
See the CLI documentation for more information on using NODE_EXTRA_CA_CERTS, as well as the original pull-request.
NODE_EXTRA_CA_CERTS=file#
Added in: v7.3.0
When set, the well known "root" CAs (like VeriSign) will be extended with the extra certificates in file. The file should consist of one or more trusted certificates in PEM format. A message will be emitted (once) with process.emitWarning() if the file is missing or malformed, but any errors are otherwise ignored.
Note that neither the well known nor extra certificates are used when the ca options property is explicitly specified for a TLS or HTTPS client or server.
There's another option for tfx-cli to connect to the TFS instance, and it is basic authentication. Just use the following format:
tfx login --auth-type basic --username myuser --password mypassword --service-url http://tfscollectionurl
Here is the quote from Github:
You can alternatively use basic auth by passing --auth-type basic
(read Configuring Basic Auth). NTLM will come soon.
Note: Using this feature will store your login credentials on disk in
plain text.