I have a secret and ipadd pair configured and worked already, but now it doesnt work when I want to change to another secret. The format is the same, only adding a few number after the old secret to test and it not work anymore, reverse back the change then all good. I tried to find how to debug it, but the freeradius -X doesnt show anything about secret, is there anyway I can do it?
Also can we use same secret to multiple client?
Thanks
Related
I have deployed an application to Heroku and have used the heroku config:set command to set environmental variables such as keys for certain things (Google Maps API, for example). When I view the page and inspect element, the key shows up in the url in the console. Should this be the case? I was under the impression that keys should be kept hidden to keep others from knowing what they are for security reasons. Please advise. Thank you.
You can't. Anything which is sent to the client is not secret. That includes any values used in javascript.
But don't worry - most API's like Google Maps use a public key. And applications where you use Oauth only allow a whitelist of callback domains.
In fact in the Google Maps Javascript API your API key is used in constructing the URLs used to request resources so attempting to hide it would be a true fools errand.
Some API's do however provide client secrets for calling the API from the server side. These should be kept secret and placed in an ENV var on the server.
I'm giving Amazon Web Services a try for the first time and getting stuck on understanding the credentials process.
From a tutorial from awsblog.com, I gather that I can upload a file to one of my AWS "buckets" as follows:
s3 = Aws::S3::Resource.new
s3.bucket('bucket-name').object('key').upload_file('/source/file/path')
In the above circumstance, I'm assuming he's using the default credentials (as described here in the documentation), where he's using particular environment variables to store the access key and secret or something like that. (If that's not the right idea, feel free to set me straight.)
The thing I'm having a hard time understanding is the meaning behind the .object('key'). What is this? I've generated a bucket easily enough but is it supposed to have a specific key? If so, how to I create it? If not, what is supposed to go into .object()?
I figure this MUST be out there somewhere but I haven't been able to get it (maybe I'm misreading the documentation). Thanks to anyone who gives me some direction here.
Because S3 doesn't have traditional directories, what you would consider the entire 'file path' in your client machines, i.e. \some\directory\test.xls becomes the 'key'. The object is the data in the file.
Buckets are unique across S3, and the keys must be unique within your bucket.
As far as the credentials, there are multiple ways of providing them - one is to actually supply the id and secret access key right in your code, another is to store them in a config file somewhere on your machine (this varies by OS type), and then when you are running your code in production, i.e. on an EC2 instance, the best practice is to start your instance with a IAM Role assigned, and then anything that runs on that machine automatically has all of the permissions of that role. This is the best/safest option for code that runs in EC2.
I have followed Stripe's Rails tutorial (https://stripe.com/docs/checkout/guides/rails) exactly (copy and pasted code), but when I run rails
PUBLISHABLE_KEY=pk_foo SECRET_KEY=sk_bar rails s
and go to localhost:3000/charges/new and fill out the fields with the test card data (card number "4242 4242 4242 4242"), but I get an
Invalid API Key provided: ***********_***
Any ideas why this is happening?
You need to plug in your publishable key and secret key; pk_foo and sk_bar are placeholders. (Unlike the API docs, the Checkout tutorial doesn't use information from your account.)
You can get them from the API Keys tab of Your Account.
i.e. for a secret key of Sk123456 and a publishable key of pk_987654, you'd issue:
PUBLISHABLE_KEY=pk_987654 SECRET_KEY=Sk123456 rails s
If that still doesn't work there are a couple things to check:
Are both keys from the same environment (test or live)? Occasionally people mix the two together.
If you load a Rails console instead of a Rails server, can you access those environment variables with ENV['PUBLISHABLE_KEY'] and ENV['SECRET_KEY']?
If you're using multiple APIs, it's possible you have some kind of collision occurring; you might try adjusting the command-line and the code to STRIPE_PUBLISHABLE_KEY and STRIPE_SECRET_KEY.
another thing you might check is that the API keys you are using are actually the right ones. What happened to me is that I was scanning the keys in Stripe Dashboard and the ones in my .env file, and made a snap judgement that they were the same based on how they started and ended. They both looked like this, with every character identical, except for the 3rd character:
sk_test_******************************D6D
For whatever reason, when Stripe rolls a new key, they keep it almost the same.
In short, don't trust your eyes, and make sure the keys are actually the same.
I'm working on the most basic Valence use just to prove it works -- using php to run a "whoami" query.
I authenticate fine, get the userId, userKey, and userSig back. I set these in the userContext object. The call to createAuthenticatedUri seems to work well -- all parameters are in the GET url I would expect to see.
I've also verified that the command path (/d2l/api/lp/1.0/users/whoami/) is valid, from another developer who is connecting to a a completely different server.
However, when I try to make the request, D2L tells me "404 Page not found".
I can make a call to /d2l/api/versions/ and that returns just fine.
Anyone have any suggestions?
Thanks in advance.
Please note that your path /d2l/api/lp/1.0/users/whoami/ is not valid: the proper route for the whoami API call is /d2l/api/lp/{ver}/users/whoami without the trailing slash, and with the right version number filled in to target the API contract you want to target among those offered by the LMS -- in your case, that might be /d2l/api/lp/1.0/users/whoami, but it's also likely that you have more modern API contracts available on your LMS as well, which you can determine using the call to retrieve the LMS' version table.
Playing with the ssh and public_key application in Erlang, I've discovered a nice feature.
I was trying to connect to my running Erlang SSH daemon by using a rsa key, but the authentication was failing and I was prompted for a password.
After some debugging and tracing (and a couple of coffees), I've realized that, for some weird reason, a non valid key for my user was there. The authorized_keys file contained two keys. The wrong one was at some point in the file, while the correct one was appended at the end of the file.
Now, the Erlang SSH application, when diffing the provided key with the ones contained in the authorized_keys, it was finding the first entry (completely ignoring the second on - the correct one). Then, it was switching to different authentication mechanism (at first it was trying dsa instead of rsa and then it was prompting for a password).
The question is: Is this behavior intended or should the SSH server check for multiple entries for the same user in the authorized_keys file? Is this a generic SSH behaviour or it's just specific to the Erlang implementation?
Yes, its a 'first failure' authentication, and I came across your issue several times. As far as implementation goes, it was explained to me that the demon iterated over the authorised_keys file looking for a matching login, and THEN checked the key.
This seems to be the standard implementation,