I am using Google Analytic API in java to get Google data for one of the website where my Google account is registered. I am able to get total number of hits between two specific dates, But I want to retrieve total number of authenticated web hits. I am not getting any proper way to get this data using Google Analytic.
The function that I have written for getting for number of hits is:
private static GaData getWebHitsByMonth(Analytics analytics, String profileId) throws IOException
{
return analytics.data().ga().get(profileId, "2013-07-01", currentDate, "ga:hits")
.setDimensions("ga:yearMonth")
.execute();
}
Can someone give me an idea about this?
Since Google Analytics has no way of knowing whether or not a user is authenticated, you have to tell it. There are two ways to approach sending this information to Google Analytics: the first (easier) is with a custom dimension, and the second (more involved, but more useful) is by using the User ID feature.
If you go the route of using a custom dimension, you'll basically just have to set that on your tracker object as soon as you know that a user is logged in. Assuming this is the first custom dimension you've made, the code might look like this.
// Set that the user is logged in.
ga('set', 'dimension1', true);
Now all subsequent hits sent to GA will include this value. (Note: you'll want to set it to false if the user logs out.)
To report on that data, you can use a filter to limit the returned results to only authenticated hits. It might look something like this: filter=ga:dimension1==true.
The second option is to use the User ID feature. The User ID is another dimension, and it allows you to track logged in users across multiple devices.
The main catch with using User ID is you are not allowed to send any personally identifiable information (PII), so it may require a bit more development work to create the User ID; however, if you're able to do that, it's probably the better route to go.
Here are some developer guides to help get you started with the implementation:
https://developers.google.com/analytics/devguides/collection/analyticsjs/user-id
https://developers.google.com/analytics/devguides/collection/analyticsjs/custom-dims-mets
Related
Instagram seems to have something called pk, i would think this is some sort od uuid for each user but it's only long and instagram has millions of users i dont think that's it. Is there any way to get a user's id or to somehow identify him even when he changes his username?
I've looked around and there isn't really a straight answer on what pk is or how to do this.
I am using this library if it matters: https://github.com/instagram4j/instagram4j
I am not familiar with the library in question, however conceptually a long is more than enough to cover all the Instagram users.
In fact, a long can represent 264 numbers, which assuming that there are 7.9 billion people in the word, is a massive 2335030895 times the entire population.
If you would simply inspect the web browser you will find the user id attached to each profile, this id doesn't change even if a user changes their username.
This same id is used to make different calls like following a user or unfollow. I use my own automation scripts and it works fine using it.
When creating a user we send the user information, create the user in the database (so now the user have uniqe id) and perform a credit check.
If a) the user has a credit score above a certain number everything is Ok (201).
b) If not we need more information from the User.
What would be the Restful way to deal with b.
Thanks
You should still return an OK / HTTP status 200 or Created / 201. As far as I understand your question your new user will be created anyway and just the subsequent credit check might fail. But the server-side and the client-side worked as expected. This is the only important thing. You could only use a 4xx if something went wrong on the client side, e.g. the user used a string in a number field. You can't use a 5xx because nothing on the server side went wrong, e.g. your credit service had an exception. The actual information that your credit service failed and more information from the user is needed should go in the body of the HTTP response.
In its current form the credit check sounds more like an RPC operation than a RESTful resource. Although the credit check might invoke a REST API of some bank which returns credit-worthy or not as a result of a query, this is not very RESTful including the check into the user-creation process (IMO).
Therefore, b) is not really RESTful in the sense that it does not deal with resources but performs an RPC like action (the credit check).
You basically have two options here:
define the whole process as atomic and declare credit properties as mandatory and create a user only if also his payment/credit/... options are available and checked positively (return 400 if something is missing or check failed)
split the user creation from the credit-check
For the latter one, you should separate the credit check from the user-creation. On successfully creating a user, return 201 (as you do) with additional links clients can use to perform the next task (HATEOAS).
As the credit check itself is not a real good candidate for a RESTful service as it is not a resource per se but more of an RPC like action (as already annotated), you probably want to refactor this code into a maybe Spring managed service bean which you inject into these resource handlers which require a credit-worthy user.
You can furthermore provide a balance sheet (/api/users/1234/balance) where a user can look up his current balance and gain actions (in form of links) a user can use to proceed further (like adding more money to his balance and so on).
If f.e. a user tries to access /api/article/yxz and this article requires the user to have a positive balance, you could return a 402 Payment Required in case the user has not enough money left.
I allow users to register on my website using a registration form.
Once form is submitted a token will be generated and will be sent by email to user, they need to click on the token link to activate their account.
My question is that if I do it, do the malicious codes can still send multiple emails to my website to register, should I use Captcha to protect the website or there is any other method ?
If all you want is to prevent double submissions, you can generate a unique token for the form that you check on submission. This requires some thought if there are multiple forms per page. Also, a simple method is to just disable the form/button on submission. This is even more effective if the form is submitted via Ajax (so that the action parameter of the form can be absent and thus not easily harvestable).
If you want to prevent automatic submissions (by bots), while Captcha is probably the strongest of the common methods, it is also very user-hostile. Instead, unless you have a reason to believe your site is being specifically targeted, it is usually enough to just use honey-pot fields (invisible fields that a human would never fill but a bot would) and hidden fields that you fill with a known value after a short delay using JS (a bot wouldn't normally execute JS nor take time to type into fields like a human). Simply doing an Ajax submission is also usually enough. I recommend using one or a mixture of these methods before falling back to Captcha.
Captcha is one of the standard methods.
Another way is do not do a direct submit of the form.Use AJAXfied server calls sos that form does not get posted by itself but has some data scrambling of inner fields & delays the submissions.
$("#contactForm").submit(function(event)
{
/* stop form from submitting normally */
event.preventDefault();
/* get some values from elements on the page: */
var $form = $( this ),
$submit = $form.find( 'button[type="submit"]' ),
name_value = $form.find( 'input[name="name"]' ).val(),
email_value = $form.find( 'input[name="email"]' ).val(),
phone_value = $form.find( 'input[name="phone"]' ).val(),
message_value = $form.find( 'textarea[name="message"]' ).val();
/* Send the data using post */
var posting = $.post( "contact-form-handler.php", {
name: name_value,
email: email_value,
phone: phone_value,
message: message_value
});
posting.done(function( data )
{
/* Put the results in a div */
$( "#contactResponse" ).html(data);
/* Change the button text. */
$submit.text('Sent, Thank you');
/* Disable the button. */
$submit.attr("disabled", true);
});
});</script>
I'm no expert in this matter, but the solution seems rather obvious to me:
Everyone uses CAPTCHA. There's simply no other way to protect your server from automated attack. It won't save you from DDoS, but will handle pretty much everything else because CAPTCHA is, well, CAPTCHA.
You do have multiple CAPTCHA solutions available though, so choose one that suits you best.
As Velis mentioned, easiest way is to use Captcha.
Other solutions exist but can be easily beaten if bots are targeted for your website, for example, having an hidden field like "re-enter email" which will be filled by bots, but can be caught on the server side and registration can be rejected.
Certain, complicated methods also exist, like recording mouse clicks or time taken to fill the form, but these require significant JS work and can be overkill until your website becomes a bot target.
Captcha is one plausible solution, but most humans don't like it.
How about instead if you add some intelligence to your system?
Implement a cooldown between emails. Before sending an email, wait one minute. If another email request comes then wait another minute and don't send the first one. (This could be another form of attack but only if this is the only line of defense).
Would a person try to register 30 times in the last minute? No.
Would a person re-register if the last register was successful? No.
You can also combine these with the IP of the registering user: Would a user try to create 10 new account for other users from the same IP in 10 minutes? Unlikely.
If this is a corporate website and you MUST prevent the email spamming, then consider secondary ways of communication. For example, if you have the means, you can request the user to SMS the email address to a specific number, which would create a reset password request.
You could also, upon the user completing the registration, generate a list of numbers that should be used to retrieve the account. Something like: "If your account is lost, it can be retrieved by entering one of these numbers into the RETRIEVE field" And then provide a list of numbers that would be confidential to your company and the customer. The same way Google does it.
Although these mechanisms can become complex, they will be smarter than any captcha; will be easier to adapt, and more comprehensive. On the plus side your users will thank you for not having to read twisted images of numbers and letters.
I have to implement custom search in my application for android 2.3.I have some EditText in which user type one letter and then I send response to the server, retrieve all the results matches this one letter and then I need to display them in a list. When user types second button I also need to send new response and refresh data and so on.
The question how can I do this in Android 2.3? What should i use?
This seems to be too open ended with too many questions to give a really helpful answer.
What you use in your app will heavily depend on how the server's API is expecting you to communicate. I, for one, am all for hiding the specifics of what a server does from the application and put all the "smarts" behind the API. So a query like:
http:/blah.com/getresults?search=a
would result in whatever matches 'a'. If it is searching a MySql Db, processing a Google search, or accessing files on the system doesn't matter.
Your code needs to worry about the interface to the API to make queries and processing the results, whether they're free formatted text, JSON objects, or whatever.
Maybe rewording your question or provide information on what you know would help.
I have a list of users across various companies who are using one of the functionality that our website provides. Whenever they contact our business group , we need to send a url via email to the requestor in order for them to upload some data. All these external users do not have any dedicated account. However we do not want a static link to be provided to them as this can be accessed by anyone over the internet. We want dynamic links to be generated. Is this something that is usually done? Is there an industry accepted way of doing this? Should we ensure that the dynamic link expires after a certain amount of time - if so , are there any design options?
Thanks a lot!
Usually, parameters to urls and not the actual urls are what's dynamic. Basically you generate params that are stored somewhere, typically on the database, and send email with the url and the parameter(s). This url is valid for only a limited period of time and possibly only for one request.
Answers to questions:
yes, this is something that is quite commonly used in, for example, unsubscribing from a mailing list or validating an account with a working email address
I'm not aware of any single way that is "industry accepted", there are many ways of doing it, but the idea is not that complex - you just need to decide on a suitable token format
normally you should ensure that the link expires after a certain amount of time. Depending on the use case that can be some days, a week or something else. In practice, you'd remove or disable the generated parameters in your database. However, if this data is something that might be needed for extended periods of time, you might want to think up a functionality so that it can be retrieved later on.
You may have a static URL taking a token as parameter. Eg. http://www.mycompany.com/exchange/<UUID> or http://www.mycompany.com/exchange?token=<UUID>.
The UUID could have a validity in a time range or be limited to a single use (one access or one upload).
Other variant is to use exists cookies on that site in web browser (of course, if they are).
But there are some drawbacks in this solution:
User can open link in different machine, different browser. User can clean all cookies or they can expire after it was visited your site last time when user try to go on granted URL. In these cases user won't access your page.