I am building a web service which i will be launching in near future. Service is more or less like online classifieds.
Now, i need to build a mechanism to collect user's information, enough to trace him in case of any fraud with other users. I can ask for nation ID card and things like that. But problem is that how will i verify them and the person providing the information.
So, i need suggestions for such system which could be used t authenticate users, so other users can trust them. And contact them freely knowing in case of any mishap authorities can get its information from our service.
For solution we must consider that our service will be free so if this process is costly, than their might be a mechanism to get that cost paid by users.
Any suggestions will be appreciated.
Related
I was unable to find a similar question posted in the past on this site. The website, OneShop, provides account automation as a paid service for users selling on the Poshmark platform (as well as other websites).
This includes listing, sharing listings, as well as other services. The number of actions against a user's account can be over 1,000 in a day. The service on the platform is not a web browser extension, so the actions are taking place directly on OneShop servers.
My questions on this topic are these, with consideration of Poshmark having no available APIs:
How is the user's account not flagged for unusual activity from an unrecognized IP address ?
How are the OneShop IP addresses, over time, not blacklisted through the course of providing service to 1,000's+ of accounts ?
What method of programming would someone use to circumvent the need of an API in this context? Spoofing IP addresses to make it appear the activity is coming from each account owner's IP address?
This is posed as multiple questions, but the core of this post is to understand how it is possible for OneShop to provide the service they offer successfully without leveraging any available API's with Poshmark.
I very much appreciate this community and frequently come here for support of all kinds in the space of programming.
The company I am working at offers a web based calculation tool which has to be paid monthly (a fixed price for a license).
Normally, users go to our website and authenticate themselves with their credentials and then can use the application. When they cancel their subscription they are not able to use the tool anymore, obviously.
Now another company called us because they want to provide our application for their own clients. We have already fixed that they have to pay a license fee for every of their clients. But there is also a restriction: their users should not have to log in on any of our websites (only on the website of our client). But the web application is hosted on our server and is loaded as an iframe.
Now there is that problem that we are not sure whether our client tells us the correct number of people who use our application wherefore we would like to verify that in some way.
One of my ideas is the following:
Our client has to call an API for every users who would like to use our application in order to submit some information like name or an unique ID of that user
When the user would like to access our application, an ID parameter is appended to the iFrame URL
I think that this is not a very good solution because our client could use the same ID for every access and pretend that only one users uses the application. By saving the ip address and id of the accesses it is possible to determine fraud in some cases because ip address will not change frequently.
We even do not have to know WHICH user accesses the application but only the NUMBER of users per month.
I am interested if there is a cryptographic solution where it is hard to cheat. Something like an authentication method which does not require any interaction of the user.
Well you can't. You should require the partner to issue a token for each user so you know they came from the partner.
You could have the partner call an api you expose to issue a one time token for a user and specify user id and IP. You could alternatively have the partner digitally sign such a login request.
If you bill the partner per user, and the partner decitfull he could claim less users.
You can fingerprint the users, you can give long term coockies, you can check IP and fonts installed etc. These will allow you to detect most types of fraud.
If you give a declared userId a cookie and then see him again without it, you assign him a new cookie and then later see the first cookie again while the partner is always declaring same id that is a very strong indicator of fraud.
If I was the decietfull partner I would pair up geographicly close users and merge their IDs. it would look no different from a user with two devices. But this still limits the extent of fraud possible. Two devices per user is plausible. 10 less so.
Find business partners you trust.
Imagine a situation where a large corporation wanting to give their users access to a website, without having to individually register each of their users with the target website.
EDIT: Registrations to the website are paid subscriptions, so normally users would pay and get their accounts activated via support line (or it happens automatically). Corporate would want to purchase a bulk subscription, and add/remove the users under that, subject to a maximum limit, so the individual users don't have to go through the hassle.
Users should still have their individual accounts with the website(instead of a single account used by all users) so that they can have their preferences saved, etc.
(Prefer a solution where most of the implementation happens in the website side)
Are there any accepted patterns, solutions for this kind of scenarios?
I thought of if we could use OAuth(Yes, I know it's authorization,
but may be we can use it as an authentication tool as well, right?),
or OpenID like protocol. But the corporation does not have such
mechanism exposed to the outside. Are there any "off the shelf" kind
of products which we could use to create a OAuth/OpenID
implementation against an existing user base, lets say
ActiveDirectory.
My Passbook-related app was recently rejected based on guideline 23.3:
23.3: Passes must be signed by the entity that will be distributing the pass under its own name, trademark, or brand or the app will be rejected and Passbook credentials may be revoked
I had a few questions and got on the phone with someone at Apple. They told me that to remedy my problem I could create a sign-up form in my application. This sign-up form could then be used to create a certificate and pass type ID for the user based on their credentials. However, I've been combing through the documentation and I've not found anything that allows people to create Pass Type IDs or Certificates without at paid developer membership. Is this correct, would my users need a paid developer membership to create their own Pass Type IDs?
If they don't, is it even possible to create a PassType ID at runtime? For example, using the information in the sign-up form I might make an API request with PassKit / some kind of Passbook server to create a Pass Type ID:
PassID *ID = [PassKit createIDWithName:#"USER_INFO"];
Is there anything like that or was the Apple technician talking about something else?
would my users need a paid developer membership to create their own
Pass Type IDs
As crazy as this sounds - yes! The only way of fully satisfying this guideline is to pay the Apple Tax and sign up as a Developer. There are several long threads in the Apple Developer Forums talking about the reasoning and implications of this. While it is not popular, the majority of us concede there are very good reasons for this, that in the long term, will protect the integrity of the platform (as well as keep the Apple lawyers happy in the short term).
The main reasoning is because in most jurisdictions; coupons, tickets, travel documents and other typical Passbook content create a binding obligation upon the issuer. Legally, in the event of non-fulfilment, the pass issuer is liable to the consumer. In order to protect themselves, Apple needs to ensure that under no circumstances, could they be deemed as the issuer of any Passbook pass.
The Apple Developer programme registration validates the identity of any individual or corporation who is accepted. It also forces Developers to sign the terms of the Developer Agreement which has an entire attachment dedicated to what you can and cannot do with Passbook and with your PassID certificate. This provides Apple with enough legal protection against any claims for unfulfilled goods or services relating to any Passbook pass.
While there has been a lot of pushback and calls for a faster, less US centric process (you would not believe how difficult it is to get a DUNS number for an small entity outside of the US), I don't expect this to change any time soon.
As for auto provisioning. Myself and the creators of the other major Passbook platforms have been calling for this since before iOS6 was launched. I have an open radar dated 7th August requesting a simple API to issue and revoke Pass Type ID certificates. I'm intrigued as to what your Apple Technician was referring to since as far as I am aware, there is no such service.
// rant
What is frustrating about this is that there are a number of approved Apps that allow full pass customisation but issue the passes under the App developer's certificate.
Apple also seem to turning a blind eye to certain services that issue passes under their own certificate that bear the logo and trademark of major brands (and then have the audacity to call on these brands to 'claim their passes').
Even Passtools (now Urban Airship) claim to offer a 'Unique Apple Developer Certificate from PassTools', which technically would be in violation of the Apple Developer Agreement.
So the bottom line is that on this occasion, you may have just been unlucky.
// end rant
I'm not sure what the technician was talking about, but 23.3 refers to a server (likely yours) going through a signing process with the pass before sending the pkpass file to a device.
For high level information, review the "signing and compressing the pass" section of the passbook programming guide.
I'm looking to implement an SMS authentication for one of my projects, basically before a user is able to register an account with us, we would like to authenticate the user by sending sms containing a code to his mobile phone, and get him to put in the code in our form before he can proceed.
I've been looking around and found onVerify to be a pretty good way to go
http://www.onverify.com/
But I'd like to know if there're any other alternatives similar to onVerify as it is a bit expensive, so if I could go with cheaper one, that'd be great.
Thanks!
You can do this easily enough if you have access to an SMS provider.
Typically you send an SMS to the user by making an HTTP request, containing the verification code. You'd store this code, and the recipient number, in some persistent database, against which you can compare when they fill in the details on the form.
You don't mention which geographic regions you expect your users to be in, which can be important given the variable delivery quality in some markets.
Have a look at the HTTP API for BulkSMS, message pricing and coverage.
Note that you can register in various regions, if you, for example, want to price in USD.
Disclosure: I work at BulkSMS