I have a C++ plug-in for MetaTrader 4 that allows me to create new accounts in it for trading purposes. I would like to be able to dictate to MT4 the account number when creating the new account. Might any one know whether this is possible and how it might be done?
The account number is generated by the broker upon account creation - So the simple answer is No; you cannot control it. The only way would be to generate an account number, and based on it anticipate what the next account number will be. This is only possible if the account number algorithm is broker-specific. This would surprise me though. I am willing to bet that account numbers are generated by MetaQuotes server with a one-way-function.
You can specify the account number in the login field of the UserRecord struct your are using in the call to UserRecordNew method. If the account already exits you will get an error from the method as apposed to RET_Ok.
If you use any API, you can manually enter the account number. If the specified account number exists, the system will reject your request. Is there any particular reason you want to enter custom numbers while opening the account?
It is not possible to control the account number. The justification of this is the fact that the account number is developed by the broker upon the opening of an account.The only way that this would be possible would be if one was to generate an account number and use this number to anticipate what the next account number will be. This approach is however, possible if the account number algorithm is broker-specific.
Related
I have built a Custom B2B app for one of our clients. My question is how to automate the distribution of the redemption codes.
I have already looked at some of the MDM providers. Their solutions are too expensive and all we really need is a way to distribute the app from a webserver, not manage a bunch of mobile devices.
As you probably already know, when a client buys a Custom B2B app through the Apple VPP program, they get a spreadsheet with valid redemption codes for the number of licenses they have built. This spreadsheet has 2 columns: 1) redemption code 2) URL to redeem the code
I want to provide my client with a URL where they can send their users to download the app. They just don't have the expertise/infrastructure to distribute the app themselves. And emailing clients is not going to work.
I'm not a web guy, but it seems to me that we could write a webpage that would look at the spreadsheet for the next available activation code and then redirect the user to the associated URL. I'm not concerned with the number of licenses they distribute since I have another way of auditing the real number of users (Flurry). So I want this to be as painless as possible.
In fact, I have multiple clients and want to provide them each with their own URL for their clients. It seems like this shouldn't be too difficult to code.
The problem is, I'm not the guy to write that code. Any ideas on how best to do this?
Assuming that you don't want to show the user a website you should be able to do this with an online service like parse.com and the features it offers.
From a user POV you would supply them with a link which directed them to parse.com with a path and parameters indicating the action to be taken (get app) and what account is associated. This would redirect the users browser to the appropriate destination.
The main issue (and this applies to any solution) is knowing if the user actually followed through and used the code. i.e. should it be removed from the DB so it isn't offered to another user in future. Then you would update the DB each time you get a new spreadsheet.
Anyway, this could be achieved with a little javascript in parse.com, specifically, by using cloud code which can interrogate and modify the DB and then redirect the user.
Obviously if you need user authentication of some kind or other restrictions then you would need to start adding some web interface on top of this in order to collect the details.
I need to know if an installation has been paid for in the past so I can provide some premium features.
Storing a payment flag in indexeddb or the file system sounds easy to defeat. Periodically asking a server and caching the response could do the trick, but I guess the user would have to be logged-in at all times (through google or otherwise) and I'd rather not impose that restriction.
Maybe if there's a way to uniquely identify a user's machine (uuid, mac address, etc) that could allow me to determine if they've made that payment?
Ultimately, this is client side JavaScript. The only means by which you can prevent use of certain features, is to put them on your server and charge for the service.
Some weak methods for preventing access include license validation, and asking the server for non-essential information (if it was essential, then see the above).
For license validation, you could create an algorithm that takes data from the user and transforms it into something else. For example, say they create an account on your website, which your server knows is a 'pro' account. You could then take their first name and email address and do some magic on it.
Here's a simple example that takes those inputs and gives us a key. In this example if our first name is "John" and our email is "john#domain.org", then our key will be fcumnflqjpBfqockp0qtifcufLqjp. However, Tony, with the email "tony#doman.org" would recieve fcumnfvqp{Bfqockp0qtifcufVqp{
You can send this key to the user, and have your code decide whether it can extract the name and email by applying the reverse algorithm.
You can reverse the strings, do various bit math, etc. It's security by obscurity. Other than an account, this is the most common method. It's used by nearly all offline software. Its kryptonite is key generators, which reverse engineer your code, and generate keys by the algorithm you use to verify them.
All the methods such as uuid, mac address etc can be easily forged imo. I think you cannot escape keeping track of user's logged-in status. Implementing something like a cookie based mechanism would be the right way to go.
I've developed an app that allows users to upload some photos and share them on Facebook/Dropbox/Twitter etc. Recently it went live in the app store.
However, I'm having a problem now: a bot is creating accounts and uploading many photos on my server. I've temporarily disabled the app, but now I'm looking for an efficient way to prevent this bot from doing this.
The bot's ip address is changing very often so it's impossible to block the ip. He creates accounts with a very realistic name and email address so it's hard to find out which users are real and which are created by the bot.
I was thinking of using a captcha, but I'm not sure if my app will be rejected by Apple if I implement this. I'm preferably looking for a way so I can prevent him from doing his work and so I don't have to resend the app to Apple again.
Could anyone give me some advice on what I could possibly do?
Thanks!
This is how I solved a similar problem:
I implemented a token-generator, which generates a one-time token for every single data transfer with the server, so even one for login-data, sending a file etc. This token is generated by a secret algorithm and can be verified server side, since you know how you generate one.
After one token is used, put it in a temporary list for the next X minutes/hours/days (depending on how many data transfers your server can handle). When a user tries to send data with a used token (i.e. the token matches one in the "banned" list), you can be sure that someone's trying to spam you -> mark the account as "spammer" and decide what you wish to do.
The algorithm must produce a different token each time (the best way would be a one-way hash), but you have to assure specific "properties", with which you can proof its authenticity.
So one very simple example:
Your algorithm in the client is generating a number between 1000000000000000000000 and 99999999999999999999999, this number is then multiplied with 12456564 and incremented by 20349.
The server becomes a specific command and data, and the generated token. Now it checks, whether (number - 20349)%12456564 is 0. If it's 0, it was likely generated by your "secret" algorithm.
It's a very basic example but you get the idea…
I have a web app that you can currently log into with either your email address or your username.
I'm developing an iPhone application and I'm just wondering if I should offer the ability to log in with your phone number. If this is the case, a user would first have to provide the service with a number on the web (an optional parameter).
I find it convenient on other services I use where I might not remember what email I have connected to it.
Is this a good idea?
Would you offer it in a service you were
building?
I'm trying to decide if its worth the trouble to build.
NOTE: This number would strictly be used for authentication.
I think that if your service is not about phone numbers (calling, texting, etc., e.g., whatsapp, etc.) I would not add phone number authentication for a few reasons:
Some users might be deterred to provide a phone number due to privacy concerns (no matter how hard you try to explain them that you will keep it safe)
With the phone number you will now have 3 options to login with, which is way too much. You want to keep your mobile login screen very simple
Some people may think that they might get SMSs from you or get their phone bill charged somehow
Overloads your backend
Just keep it simple...:)
To add to that, I personally prefer just email, without a user name. So many sites require user names AND impose restrictions on how this user name should be structured, so you end up with tons of them. With emails, you can't go so wrong - most people use a primary one to sign up for sites.
Hope that helps.
How do you get the total number of users in a Google Apps Domain? I'm aware of the "Retrieve All Users in Domain" call using the Google Provisioning API, but I'd rather not execute such an intensive call just to count up all the users. Is there a simpler way to do this?
I found a solution that isn't as resource-heavy as retrieving all users: The Google Reporting API can be used to get the total number of accounts in a Google Apps domain.
The Google Apps Admin Settings API allows you to retrieve both the current and maximum number of users in the domain:
https://developers.google.com/google-apps/admin-settings/#retrieving_the_current_number_of_users_in_a_domain
this would be preferable to the reports API as it's both lower in traffic and it's closer to real time (reports are only updated every 24 hours so it won't take into account users recently added).
You could try "Retrieve All Nicknames in Domain" which could save some bandwidth as it hopefully really only retrieves the nicknames, although I think this won't get you the exact count because "Retrieve All Nicknames for a User" seems to imply that a user can have multiple nicknames.
If you've got some test domain, also assure that retrieving all users really is too much overhead and keep in mind that depending on what you want to do, you can perhaps build some kind of cache around it that only does a full request after the cache is older than X.