I've built a web booking system that signs people up for courses.
In order to provide the best web experience I've been logging the user agent.
It's a .Net 6 project. I am using this to get the user agent.
string userAgent = Request.Headers["User-Agent"];
I was under the impression that almost all browsers will return a user agent string and that if it's null then it's likely to be a bot.
However, several of these users have gone on to complete paid bookings successfully so are clearly not bots.
The question is. What browser does not return a user agent string? I am finding 95% of users are on mobile devices. Or, does the above code not work in some circumstances?
Are there incognito browsers that don't sent user agent?
Related
I have a problem that I need to solve for my client. The situation is that they have a lot of users on one platform (platform_1). In order to use the platform a user must be signed in, therefore these users (credentials) are given out to clients for them to use the platform. The problem is that one user (one set of credentials) may be given out to a few clients, therefore we cannot know which of the clients did what (in this case - bought something) on the platform.
Figured I would just create a new system where the client can be created and a set of credentials would be attached to that account, then I would just display an iframe of that platform (platform_1) with the attached credentials on the newly build platform and then I would be able to track what the user is doing in the platform.
But turns out iframe cannot handle credentials and also it would not be safe to use this method..
Also thought about scraping the whole platfrom (platform_1), which would work, but then I believe it would be extremely hard to do live auctions, for example scrape the live auction and display it on my system and let the user click on some buttons and the script would do the same on the platform_1, but the delays and overall usage could make it very hard.
I would like to kindly ask you to share your thoughts on ways this problem could be solved or whether it aint possible.
If you log into a platform (Twitch, Blizzard, Steam, Most Crypto exchanges, Most Banks) from a new device you'll typically get an email stating so.
As far as my knowledge goes, the only information you can get on a request is
IP address
Device Operating system & version
Browser type & version
Are these platforms basing their "unique" users off of this information alone and/or am is there more information that can be gathered?
From a security perspective the largest thing is your identity or how you authenticate. That's king. The email stating "hey this is a new device" I've seen handled differently from site to site. Most commonly it's actually browser cache and I see banks specifically use browser cache to store these kinds of tokens. Otherwise every time your cellphone connected to a new cell tower you'd likely be flagged as different. They're not necessarily the same as an authentication token, rather it just says hey I've authenticated as this user to this site before. Since it's generated by the service provider, the service provider knows to trust it, and it's nearly impossible to hack (assuming it's implemented correctly).
From my own experience the operating systems and browser types, that's more record keeping than actionable insights, however you could build a security system that takes into account an IP address from very different geo-locations. I.e. why is this guy from the US logging in from China. They just logged in from California 3 hours ago, this is impossible. I don't believe most sites really go to that extent though. I do see MFA providers saying "hey there's a login from china, do you want to approve?". That workflow makes a lot more sense.
The last part of your question is tricky, regarding "unique users." Most calculate that based off the number of sessions opened (tabs), or in the case of Twitch (since you mentioned them specifically), the number of tabs that are streaming that video in. These open platforms where anyone without an account can stream the content obviously treat this differently than say Netflix that makes you authenticate and each account has a limited number of sessions that can be open.
AFAIK, most of the systems like this stores a cookie in your browser when you log (not the session cookie, just a random ID) that is also assiciated to your account in the provider database, so when you came back, you log in, and they check whether you have that cookie set and in case if the ID matches
They you can probably do some more advance stuff with that ID, like base that value from the browser, OS, expire date and so on
I have the following intent and followup intents for a user login process:
How can I set a while loop for this login process in order to continue asking user email while user enters email address incorrectly and after he/she enters it correctly the getting password intent triggers?
In my cases after 2 incorrect entry, api.ai will response "Not Available".
Forcing users to respond to a question without giving them recourse to cancel, move to another part of your conversational interface or speak about another subject is user-hostile and I'd recommend doing exactly what Actions on Google forces you to do in this situation: end the conversation after a few failed attempts.
Conversational interfaces are best thought of as designing actual conversations. In a normal conversation asking the same question multiple times regardless of what someones says to you would largely be considered annoying at best. Consider revising your Dialogflow agent to allow logged-out conversations explaining to the user what your agent can offer and why login is required for certain features. If the user repeatedly asks for a feature that requires login but refuses to do so, the conversation should end.
Another note here: I'd recommend against using passwords through conversational interfaces. Most conversational platforms have a way to sign in (e.g. Google Assistant/Actions on Google) or you can safely assume the user is using a device where they have access to a web browser as well (Slack) and you can use a system like OAuth to properly authenticate users.
I've been developing and maintaining a Chrome extension for my company where each customer would be assigned a unique ID in the code. We've been using the ID to determine license status and login to our services (paid extension with monthly subscription fee).
So far we've hosted the extension files ourselves and had unique update URLs for each customer extension. This has been nice and simple; go to our website, click install and you're done. With the latest Chrome release, however, that installation procedure has been thwarted by Google since they now require users to install extensions by dragging and dropping the CRX files into the chrome://chrome/extensions/ tab. Unless of course your extension is available through Chrome Web Store - which leads me to the problem:
We don't want the drag and drop CRX installation - requires Web Store.
We don't want multiple versions of the extension (one for each customer) on the Web Store since that's a maintenance hell every time we update the extension.
We don't want to use Web Store licensing because:
It requires OpenID login.
We sell the extension to schools with many students where the school pays the bill - not the student.
We don't want to lock our payment method to one browser, i.e. we want to be able to maintain licensing and payment through our or servers.
We don't want to have users input a license key since that's too much of a risk with several thousand students having to input the key - also it requires some kind of storage (cookies/localStorage) which would eventually get cleared requiring the license key to be input again.
I'm not 100% certain that my statements are completely correct, so feel free to enlighten me if I missed something.
If they are, the question is whether or not we can somehow tailor the extension for each customer through the Web Store (using the unique ID) without needing to publish one extension per ID?
As a side question any answers that might solve the problem with another method will also be accepted.
For the answer below, I assume your app is a packaged app, not a hosted app.
I have a solution that's fairly similar to your current implementation, but adds one extra step for users. For the student user, the process will work like this:
Download the app from the Web Store. The app does not function yet, and launching it just displays a "Please click the activation link provided by your school/institution" message.
Click a link hosted on your server (i.e., the server where you used to host the update URL) that looks like https://myserver.com/activateapp.php?custid=123456789. You host one such link for each institution you support, and it is the institution's job to provide its link to its students. This link activates the app.
From an implementation point of view, here's how it works:
Host a page, https://myserver.com/activateapp.php, on your server. Server-side, check that the custid parameter is valid. If it is not, send a 404 error.
Your app has a content script that is injected into https://myserver.com/activateapp.php that scans the URL and picks out the customer ID. Once the app finds the ID, it stores it in localStorage. Since invalid customer IDs produce a 404 error, you know that when the content script runs, the page is not a 404 error; therefore, it is reading a valid customer ID.
Any time the app wants to query your services, it checks if it has a customer ID in localStorage. If it does, it uses that ID; if it does not, it displays a message that the app has not been activated yet. Packaged apps will never have their localStorage erased unless your app is programmed to wipe its own storage, or the user does it from the console. Storage erasure will never "accidentally" happen. Even the strongest browser-wide data/cache purge will only clear localStorage from Web pages, not from apps and extensions.
For extra security -- if you don't want people randomly guessing customer IDs -- you can add an extra signature parameter, like https://myserver.com/activateapp.php?custid=123456789&sig=2464509243. This extra parameter is some server-verified transformation of the customer ID (ideally a cryptographic signature or a purely random value associated with the ID in a database) that is impossible for anyone to guess. When the request for activateapp.php hits the server, it checks for a valid customer ID and a valid corresponding signature. Of course, this doesn't stop people who have legitimate access to a valid link from sharing the link to unauthorized people, but I expect that was a vulnerability that existed in your old system anyway.
We are currently looking at the possibility of a jquery mobile app for company employees. But, we don't have a ton of experience and would like suggestions on how to do security?
Background:
Salesmen with Android phones or Iphones
most of the time on foreign wireless or 3g/4g, sometimes on intranet/internal wireless.
Would like app to show customer info, current orders, pricing, etc
Windows 2008 Active Directory environment.
Obviously because of the sensitive customer data, security would be fairly important.
Just barely researching jquery mobile, and wondering what the ideas for security are out there?
Also, all the phones are company provided, and we have access to the full phone, would using something hardware/os related on the phone provide extra security? A hash of the imei, phone number, mac address, etc?
Thanks
Run the company portal on HTTPS - assuming you are just building a regular site. If you are planning on wrapping it in a e.g. a PhoneGap layer, be sure to communicate securely.
Make the backend API stateless (no sessions) and provide the full authentication credentials in the AJAX headers. You'll want to transmit username, password, and device ID over SSL on each call that way you can authenticate the device in addition to the user.
You can manage the equivalent of a session timeout on the app itself using setInterval() in javascript. When the timeout expires just clear the user credentials in javascript and have the app go back to the signin screen. You can also add a check on the beforepagechange event in JQM to see if the user is authenticated and, if not, redirect them back to your signin screen.