From what I've read, conventional wisdom is to generate a new Bitcoin address for each payment you're going to receive. However, since Heroku's file system is read only, where would you store the keys for each new address? bitpiggy.herokuapp.com is running on Heroku and appears to accept Bitcoins. Does anyone have any idea how they accept and handle Bitcoins on the Heroku platform given that the file system is read only?
They appear to be using a 3rd party supplier, e.g. blockexplorer.com or blockchain.info, for Bitcoin services. See their "developer resources" page for the API they wrote to access those.
You could also create such a service yourself, just run it on EC2 or a rented server/VPS.
Related
I have a Forge App (which, of course, is nothing more than a clientID/secret for establishing an OAuth connection). I saw a reference to "production", but couldn't find any info on how to promote it or get the production clientID/secret. Does this exist, and if so, how do I do it? Or is my app automatically in production?
When I did the exact same thing (OAuth App) with Procore, they had a very clear distinction between the initial "sandbox" environment that you used for dev & testing; and once you were ready, you made a request to promote the app to production and received your prod clientID/secret. Forge is not so obvious, but maybe I am expecting something that simply doesn't exist here.
Also, is it possible to list more than one callback url, and if so how? I need current up-to-date info on this, not answers from months or years ago. (I have seen old answers that mention a wildcard [*] but also users say that it doesn't work; and even that doesn't work for my urls, which are not identical in structure.)
Thanks!
Forge apps do not differentiate the environment. You can create multiple apps, one for each environment. The API and features are the same. That app connects to BIM360/ACC, in which case we would recommend having 1 account for testing/validation/sandbox and, later, you connect to multiple customer accounts.
As of today, we do not support multiple callback URLs, but we're working on this feature.
I have an application hosted on Amazon EC2 on a Ubuntu machine, written in Ruby (on Rails), deployed with Capistrano and running on Nginx.
Last friday one module of my application has crashed and nobody in the company noticed until this morning. We spent some money with Facebook and Google ads and received a few hundreds of visits, but nobody created an account due to this bug.
I wonder if this configuration is saving the HTTP requests and its bodies somewhere in a log file. But we didnt explicitly set it, so it would only happen if any of these technologies do it by default.
Do you know whether there is such log or not?
Nope, that wouldn't be anywhere in a usable form (I'm inferring you want to try to create the accounts from request bodies in log files). You'll have the requests themselves in your nginx logs, and the rails logs will contain more info about the request, but as a matter of security, by default, any sensitive information (e.g. passwords) would be scrubbed from them. You may still be able to get some info from them.
To answer your question a little more specifically, the usual place for these logs on your system would be:
/var/log/nginx/
/path/to/your/rails/app/log/production.log
On a separate note, I would recommend looking into an error reporting service like Honeybadger, Airbrake, Raygun, Appsignal, or others so that you don't have silent failures like this moving forward.
I would like to integrate my cloud service in Heroku as an add-on. I read the available tutorials on how to do this, but it is still not clear. https://devcenter.heroku.com/articles/building-a-heroku-add-on#provisioning
I couldn't understand the role of the application that we create from a template (Sinatra for example) using kensa.
Is it an intermediate between Heroku and the cloud service?
thanks in advance.
Actually, Heroku needs 2 things:
addon-manifest.json file where described all information needed for Heroku. And this json file contains 2 important urls:
'base_url'
'sso_url'
Application which will server heroku-specific API and responds wit corresponding JSON on provisioning/deprovisioning/planchange requests. These request point to 'base_url'.
So, if you own your Cloud service code, and can add new API endpoints, then you don't need any application based on kensa-template: add necessary API controllers directly in the service.
But if you can't upgrade the cloud service, then you're right, kensa-template is a ready to use with heroku intermediate.
In case of sinatra template, you just need to put necessary API calls to your cloud service in "# provision" method of app.rb file, deploy app somewhere and do 'kensa push' for your addon-manifest.json (don;t forget to update base_url to yours)
Good luck!
Bare minimum API routes for heroku add-on based on your Cloud service:
POST request to '/heroku/resources' - for provisioning
DELETE request to '/heroku/resources' - for deprovisioning
If you really want to sell it to heroku users, then you should do more stuff:
add support for heroku single sign-on
this is one more API route: POST to '/heroku/sso', but you can change it in addon-manifest.json file.
PUT '/heroku/resources/:id' for Plan change request. Note that ':id' is an id which you provided heroku in your response during provisioning.
If you implement SSO, then user can click on your add-on on heroku instance's resources page and redirect directly to your service bypass any login forms.
You can show just short info about user's resource in the page after SSO.
I'm trying to implement a webmail in PHP. I would like to write a PHP CLI script which is run on every email arrival to store some parts of (not all of) incoming email into database for search purposes. Then when the user finished searching and chose an email to show, a connection is made to mail server to retrieve the complete email. In order to implement this scenario I need to make some sort of connection among emails within database and mail server.
Since my knowledge of working with mail servers is limited to Zend Framework's API, what I believe I need in order to retrieve an email from an IMAP server is a message number or a message unique id (this later one seems not to be supported by all mail servers).
To this point, I've managed to find .forward (and some other ways) to introduce my PHP CLI script to MTAs to be run on every email arrival. This way I can store emails to database. But this won't do since message unique id is created by MDA so MTA do not know of it and they can not provide it to me. This means I can not find emails later when I want to retrieve them from mail server.
At last, here's my question: Is there a way to introduce a PHP CLI script to a MDA for emails' arrival? If this is dependent on the mail server, which servers do support this and how? My personal choice would be Dovecot or Courier, but any other mail server would do as well.
This is tricky -- there are many ways on how to setup delivery. Some of them work with the underlying mail store directly, bypassing your IMAP server altogether, while others use e.g. Dovecot's facilities.
Have you considered building on top of the notify plugin which ships with Dovecot?
It seems like it's impossible to introduce such a PHP CLI script to IMAP server (at least I'm sure of Dovecot). Anyway, the work around I found for this problem is to use my own PHP script to insert the new mails into IMAP server and retrieve their id's and then store the id in database for future references. To be clear, email are given to my PHP CLI script by MTA, not MDA. As I said before this is done easily using .forward file.
[UPDATE]
Unfortunately it seems this solution can not be implemented as well. The way to insert a new email to IMAP server is APPEND command, and to have the UID of the recently added mail server must support UIDPLUS extension. Neither Dovecot nor Courier supports this extension at the moment! If they did it seems the server would return the UID with a APPENDUID response.
[UPDATE]
It is my bad since Courier does support UIDPLUS. So this solution is valid and the one I'm going to implement.
My Delphi program has a built-in protection mechanism to check for banned license keys on the Internet and displays a message to the user if a blacklisted key is found.
I'd like to store the blacklisted key in the registry, so if the user tries to re-enter it (and he/she is not connected to the Internet), it's not accepted.
What is the best way to hide an obfuscated entry in the Windows registry?
Thanks!
Edit: You guys have some good answers there, but I feel like I need to expand the question.
This is not mainstream software but a corporate one. Clients pre-pay one year and get a one-year license key for activation. The license key includes a machine ID and can't be used elsewhere.
The problem is that some clients tend not to pay in time or they don't pay at all. Since I don't want to bother with shorter than one year license keys (too much administrative overhead) I need a way to disable their licenses till they pay.
So the app now will connect to the Internet upon launch and check if their key is blacklisted. If it is, I need to disable access. In case they reinstall or block Internet access, I need to know if the key has been blacklisted.
Thus, I'm thinking it would be best to hide it in the registry. My users are not tech-savy enough to use registry tools to monitor the registry, but if I put it under HKLM/Software/MyCompany/MyProgram, some of them might do find it. So I need a place where they can't find it afterwards that it had been created. (Noone will be expecting it!)
Any ideas?
The eaysiest way to hide a key or a value is to create a key/value having '\0' inside of the name. You can do this wth respect of the native functions NtCreateKey (see http://msdn.microsoft.com/en-us/library/ff556468.aspx) NtSetValueKey (see http://msdn.microsoft.com/en-us/library/ff557688.aspx) which use UNICODE_STRING as parameters instead of LPCTSTR. You can read more about usage of native registry API in http://www.codeproject.com/kb/system/NtRegistry.aspx for example. A Delphi code you will find here http://www.delphi3000.com/articles/article_3539.asp.
UPDATED: Because many people read this question I want to add some words to my answer. I want divide the part of the question which we can read also in the title "best place to hide a key in the Windows Registry" from the subject with license keys. Because I read some answers (written before me) which concerned almost only the part of license keys and read practically no answer on the question from the title I wrote me answer.
The subject with license key I find very complex. It depends on the licensing model choosed. It's important how to generate, to distribute (to install) and to verify the key. Is key should be hardware depended or not? It can be one per computer or one per computer group. The key generation, key installation or key verification can be either with respect of some online services (also from the internet) or without there. I can continue... There are a lot of aspects, advantages and disadvantages of different approaches.
So I decide to answer only on the main question from the title which is clear and have a separate interest. All other questions about license key should be discussed in my opinion in the separate question after clearing all requirements.
UPDATED 2 based on the updated question: It seems to me in your case would be better to use some scenario based on cryptographic signing of an activation ticket. For example the schema can looks like following:
You software installed on the client computer will need an activation. Before activation it can not work or work in very restricted form (for example only some menus needed for software activation are enabled).
You write a server component which will be used by client during the activation to generate the license key based of the activation request received from the client.
If a client pay for the software you include the information about the client's "machine ID" (in any form which you want) in the database on the server.
After starting of the activation process from the client software (either at the program start of from menu or in any other way like you want) it collects some information about the computer like computer name ("machine ID"), some serial numbers or some other information about hardware or operation system which can not be changed without a new activation. This information the software send to your server (it is the activation request).
The server verify that the the client with the "machine ID" payed for the software and is not yet activated. Then the server calculate the hash (SHA1, MD5 or some other) from the information send from the client and sign the respond with the server's private key (or servers certificate). The signed ticket server will be send back to the client. This ticket will play the role of licence key.
The server can add any additional information to the ticket before signing. For example it can add the information about the date till one the software should be valid (for example, current day plus one year). So the ticket which will be send back to the client can contain the hash of input activation information and any additional information, all what you want. Important is only that the information should be signed. In general you can include full client's request as clear text in the servers ticket instead of including of the hash, but the usage of the hash a) reduce the ticket size and b) makes the ticket a little more secure.
Every client have public key corresponds to the private key used by server for signing of the activation ticket. The client save the ticket received from the server during activation in any place in registry of in the file system.
Every next time if the client software will be started the software will read the saved activation ticket from the registry (or from the file system). Then the software collect the same information, which are used for generation of the activation ticket, calculate the hash and compare it with the hash from the saved ticket. It verify of cause the signature of the ticket with respect of the public key (or with respect of the server's certificate). Moreover the software can verify any other additional policy information from the ticket like the time till one the ticket is valid.
All written is a roughly schema only, but it is very simple and it is extensible. You need only study how use some simple cryptographic operation and implement there in your software.
As a option you can don't have a server online, but instead of that implement in the software (in menu for example) a possibility to generate the activation request and send it per email for example. Then you can offline (!!!) generate an activation ticket based of the server request and send the ticket back to the client also per email. A simple Reg-file which can be imported by double-click or some other simple import possibility in your software (cut & paste in the activation dialog) can end the process of the software activation.
I don't think that the registry is a good place to hide such info, because anyone can download and use the Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) tool and see what your program does with the registry.
And thinking about this again. You will probably make users of your software unhappy if it will leave things in registry and other "secret" places on the user's hard drive. Locations like that are also easily discovered by tools that monitor what system functions your software calls.
As an alternative you could embed the banned keys in your application when you release new versions. This way the banned keys will be hidden in the application making it much harder for crackers to bypass the protection.
The downside of this is that a user can potentially run older version with a banned key with internet access blocked to your site, but if your software is actively developed with new features and bugfixes added, then nobody would want to run older versions. And if you are very paranoid you could release "updates" which update just the embedded banned key list.
But in the end no software protection scheme is perfect. If your software is popular enough there will always be a pirate cracker who will figure out your protection and make a patch or even a key generator.
If you really want to go that way, hash or encrypt the keys and then check the hashed or encrypted user key to those on the registry.
Be sure to check if there's any keys in the registry to be sure if the user didn't erased them.
It will be very challenging to achieve what you're trying to do, since a user can simply uninstall and re-install, and savvy users can wipe all traces of your app from the system (including the registry).
Other apps (like Windows, for example), instead of checking for a negative (banned key), instead check for a positive (good key). You "activate" the software once (when connected online) and this activation stores the "good key", which you can then check for whenever running the software (whether online or offline).
I'd suggest the second approach for you.
Note that there are ordinary end-consumer tools that monitor what applications write to the registry (like Cleansweep). This goes on API call level, so it will probably catch #0 workarounds too.
You could try to encrypt the whole shebang in a registry key, with something that uniquely identifies the machine (like a mac address) and a timestamp, to avoid that people can move the key to other machines. THen always require the presence of such key to startup, and demand to connect to internet for updates/activation if it is not there. (or the timestamp is very old)