I have integrated Stripe into my Ruby Application. When testing on LocalHost on my iMac everything works fine.
The deployment in production works fine
When testing on my MacBook Pro it errors out on submission. The MacBook and iMac are using the same operating systems. iMac late 2014, MacBook late 2016.
This is my first stripe integration and I am stumped.
There are no differences in code, and so I am considering that the environment is not initialising, but I don't know what the issue is.
The error is as follows:
"No API key provided. Set your API key using "Stripe.api_key = "
Showing the following code as the culprit - But remember this works well on two other installations and so I can't see it being the code at fault (But I am happy to be wrong if you all have other ideas!)
Stripe::Customer.retrieve(stripe_id)
else
stripe_customer = Stripe::Customer.create({
email: email,
})
This is the config file
stripe.rb
Rails.configuration.stripe = {
:publishable_key => ENV["STRIPE_TEST_PUBLISHABLE_KEY"],
:secret_key => ENV["STRIPE_TEST_SECRET_KEY"]
}
Stripe.api_key = Rails.configuration.stripe[:secret_key]
StripeEvent.configure do |events|
events.subscribe "charge.succeeded", Webhooks::ChargeSucceeded.new
events.subscribe "customer.subscription.deleted",
Webhooks::CustomerSubscriptionDeleted.new
end
Related
I'm working in Chrome for MacOS (108.0.5359.124) and Microsoft Edge (107.0.1418.62) on MacOS 12.6.1 (though confirmed the same issue on 13.0.1 as well), and the reset() method of WebUSB does not seem to work - I get no error on the console, but the device also doesn't see the reset.
Meanwhile, the same code does generate a USB reset in Chrome on Linux (same version, 108.0.5359.124, under Ubuntu 18.04 with kernel 5.4.0).
The code is here:
const connectButton = document.getElementById("connect");
const resetButton = document.getElementById("reset");
let device;
connectButton.onclick = async () => {
device = await navigator.usb.requestDevice({
filters: []
});
await device.open();
console.log("open:", device);
await device.selectConfiguration(1);
console.log("select config 1:", device);
await device.claimInterface(0);
console.log("claim interface 0:", device);
};
resetButton.onclick = async () => {
console.log("Device before reset: ", device);
await device.reset();
console.log("Device after reset:", device);
}
I see all the console logging, and no errors are thrown. (If I try to claim one of the HID interfaces on this device, I do get errors - but I believe that's expected). I've also tried without the device.selectConfiguration() and device.claimInterface() calls - exactly the same behavior (ie, no errors, but it doesn't work).
Is there something under MacOS preventing it from sending the reset? I can get similar code working on MacOS under node.js using WebUSB calls, but I suspect it's actually using libusb under the hood... I should say that the device in question has firmware written in Zephyr 3.0 (I wrote a substantial part of it). I haven't gotten resets to work with other devices either, though.
According to https://bugs.chromium.org/p/chromium/issues/detail?id=1189418, it seems like USBDevice.reset() does not work properly on macOS.
Even though a patch was submitted to fix this behaviour, it was reverted due to an expected libusb issue: https://chromium-review.googlesource.com/c/chromium/src/+/2936179
I've pinged the Chromium team at https://bugs.chromium.org/p/chromium/issues/detail?id=1189418#c15. We may want to follow up there.
I have built an API with Spring-Boot, which send some JSON as response.
After I set the #CrossOrigin-Annotation on my Spring-Boot-App, I‘m able to fetch the data without any problem.
Now I want to fetch from the same API with my React-Native-App (running with Expo App (iOS)).
Unfortunately I only get an Network-Error.
I added Localhost:19002, the IP from the Expo-Server and my Phone-IP to the CrossOrigin-Annotation.
Same Error.
The API should be fine, so my Question is:
What IP is Expo using, to fetch my Data from the API?
I hope, someone can help me - as I‘m pretty new to this (Web)App-Topic
Greetings
Daniel
If you are running the Expo client app on your device, localhost will refer to your phone and not your computer.
You will need to use your network ip address for your computer to reach it. You can get that programmatically while in development by using Constants.manifest.hostUri but that will include the port as well.
// be sure to run expo install expo-constants first
import * as Constants from 'expo-constants';
let host;
if (__DEV__) {
// eg: 192.168.1.1:19000 -> 192.168.1.1
host = Constants.manifest.hostUri.split(':')[0];
} else {
host = 'https://your-production-server-url.com/api'
}
Folks,
I am trying work on a simple Web MIDI app.
I already looked up and found out that Google Chrome is the only browser that supports this. So, I installed this but I still get this.
WebMidi could not be enabled Error: The Web MIDI API is not supported
by your browser.
at WebMidi.enable (webmidi.min.js:30)
at script.js:430 (anonymous) # script.js:432 WebMidi.enable # webmidi.min.js:30 (anonymous) # script.js:430
Promise.then (async) (anonymous) # script.js:154
Mac - 10.15.2
Chrome - 79.0.3945.117
According to this link - https://www.midi.org/17-the-mma/99-web-midi , Chrome definitely has the support.
Important Note - If I were run the code directly on codepen, it works just fine. So the browser is working. But when I try to run locally, I get the error.
https://codepen.io/teropa/pen/JLjXGK
WebMidi.enable(err => {
if (err) {
console.error('WebMidi could not be enabled', err);
return;
}
What am I missing here? is this a chrome issue or Mac issue or some permission issue. Or, is there is something specific I need to make the MIDI code run locally?
I am using this server, https://www.npmjs.com/package/http-server, to run the code locally.
(I have looked at other questions but did not find anything that relates to Chrome on Mac)
I've used web-midi with Chromium and Opera on 10.12.6, so I wouldn't say that Chrome is the only browser that has web-midi.
With Opera I think I had to enable experimental features:
chrome://flags/#enable-experimental-web-platform-features
Maybe see if Chrome needs that too?
Or maybe it's just a side-effect of all the lock-down in 10.15?
if serving dev site from 0.0.0.0 you won't get any MIDI in browser, but when loading from 127.0.0.1 it should work ( as commented by user Alex above )
I'm trying to do authentication on my Android application using Xamarin.Auth. Some time ago, Google made the policy that you cannot do this in an embedded web view (for totally valid reasons).
I'm trying to open the account authentication page in a browser, but keep getting the embedded web view. I understand that isUsingNativeUI needs to be true in the following code:
_auth = new OAuth2Authenticator(clientId, string.Empty, scope,
new Uri(Constant.AuthorizeUrl),
new Uri(redirectUrl),
new Uri(Constant.AccessTokenUrl),
null,
isUsingNativeUI = true);
At every point in my application, this always equals true.
Elsewhere, I have code that redirects to what should be a browser:
var authenticator = Auth.GetAuthenticator();
Intent intent = authenticator.GetUI(this);
this.StartActivity(intent);
Regardless, I keep getting a dreaded 403 disallowed_useragent error whenever I try to run the project. Is there another element to this that I'm missing?
To my knowledge, setting auth.IsUsingNativeUI = true in the constructor should dictate that it must open in a browser. I've been following this example to try and debug with no success. I even pulled the guy's repo down to my machine and ran it - the Intent variable at the moment of redirection is almost identical.
Could there be something stupid that I'm missing? What else might be going wrong?
I realize this is an old question, but I had the same issue.
You have to install version 1.5.0.3 of the Xamarin.Auth Nuget package. The newest one (version 1.7.0 right now) doesn't work. You'll have to also install the PCLCrypto nuget package in order to get that version to work.
This may well be a duplicate question, but no answer from an existing question has solved my problem.
I have a WebAPI end point running on my dev machine. I've configured it to run on
.UseUrls("http://localhost:57971", "http://10.0.2.2:57971", "http://192.168.44.1:57971", "http://192.168.1.48:57971", "http://*:57971")
where:
192.168.44.1 is Desktop Adapter #2 on the emulator Networks settings tab
10.0.2.2 is the special address for the Android emulator, as set out in Google's doco (possibly not relevant to Xamarin) and
192.168.1.48 is my local IP address for my dev machine.
I have created a firewall rule permitting connections on TCP port 57971.
I researched this pretty heavily and heeded instructions such as those set out here http://briannoyesblog.azurewebsites.net/2016/03/06/calling-localhost-web-apis-from-visual-studio-android-emulator/
I'm kinda out of ideas. The annoying thing is, it fails silently. There is no exception and the output just basically shows the different threads exiting with code 0. And the application keeps running i.e. the debugging session is not returning the IDE to a "code entry" state. This may suggest that something else its at play here.
The code looks pretty innocuous to me:
protected async Task<T> GetAsync<T>(string url)
where T : new()
{
HttpClient httpClient = CreateHttpClient();
T result;
try
{
var response = await httpClient.GetStringAsync(url);
result = await Task.Run(() => JsonConvert.DeserializeObject<T>(response));
}
catch
{
result = new T();
}
return result;
}
I'm using Visual Studio 2015.
I'm using the Visual Studio emulator https://www.visualstudio.com/vs/msft-android-emulator/
Any idea how I can get wheels on the ground on this thing?
Is there a way to Ping my machine from the emulator?
Thanks
I got this working by using 169.254.80.80 i.e. I added it to the list of urls which the API serves and called that ip address from the Xamarin app.
So, in Program.cs became simple:
.UseUrls("http://localhost:57971", "http://169.254.80.80:57971")
I also had to add it to the bindings element ApplicationConfig file in the hidden .vs folder of the ASP.NET API solution. Not sure why it had to be 169.254.80.80, as that was Desktop Adapter #4.
That got it working.