Im using Matomo for tracking user's page visits. Things that I'm getting is userId, and pages which user visited nothing more. Do I still need to request for consent? Im not sharing user data with any other apps.
You are close. Two caveats:
Matomo will store the URL. If you send GET requests with http there can be Names and personal information in the stored URL
I am assuming you are anonymizing IP addresses? Matomo allows partial anonymization or full anonymization. This removes Geo data.
Check those two things and you are probably good.
Depending on whether you are staying compliant in EU or a specific EU country, interperetation of GDPR and PII (not identical) will vary a little. Matomo has some guides for checking config settings for all of these in Matomo:
CNIL https://matomo.org/blog/2021/10/matomo-exempt-from-tracking-consent-in-france/
GDPR https://matomo.org/gdpr-analytics/
PII https://matomo.org/blog/2018/04/how-to-not-process-any-personal-data-with-matomo-and-what-it-means-for-you/
These are helpful for confirming which settings to apply and whether to modify the default settings.
Related
I have "unverified app screen" when I request access to Google accounts.
To get rid of it I want to fill out OAuth Developer Verification Form. But, I got some problems with that due to some restrictions on my environment.
There is a field:
Homepage URL for your app *
The problem is that in my application my home page is not accessible publicly. Usually, it can only be accessed using VPN connection.
For push notifications, I use different URL that only handles them, but for the UI there is no access from the world without VPN. I was thinking of overcoming the issue and have a few ideas, but I'm not sure whether they will work.
Inform Google of restricted access to the home page via this field:
Is there any other information you can provide that will be useful?
However, this approach might not work due to the fact that it's not said that I can omit to specify the home page.
Find out what addresses google requests homepage from and to allow access to it from those addresses. But, firstly it's insecure and secondly, it's still a question how to get these addresses.
Make some static resource stub page and place it somewhere where I can provide access. For instance, I can put it near privacy policy file that is publicly accessible.
Is there a more suitable way of addressing this issue or some of these options might still work?
In my application, I am getting an access token via ADAL's acquireTokenSilent() for one resource, which succeeds, and then I try to get an access token for another resource and it says it was not found, and hence I have to call the API to explicitly prompt for credentials. This is a problem since then the user has to login twice with the same credentials in order to access two different resources.
I am using the same authority for each resource. Here is the message that shows there is no hit in the cache for the second resource.
May 4 13:22:37 iPad MyApp[290] : ADAL 2.4.1 iOS 10.2.1 [2017-05-04 20:22:37 - XXXX] INFO: No items were found for query: (resource https://MYRESOURCE + client + authority https://login.windows.net/common)
So my question is, under what circumstances will tokens be shared across resources, and is there any special allowances (ways to use the APIs) which allow this?
If you are building two native clients (public clients) and you want to enable single sign on across the two, one option is to share the App ID between the apps versus passing the actual token from one service to another service.
For example lets say your company name is Contoso. You have a Calendar Mobile App, and a Document Editor App.
You can create a single Native Client Application with:
A common application name, like "Contoso Apps"
Redirect URIs for both apps
Permissions required for the sum of the two applications
Then when a user signs into either application, they will see a login screen with the generic name "Contoso Apps", and prompted to consent to permissions for both apps at the same time. Now this might be a little bit of a bad experience, since the permissions of the two will probably be more than the individual permissions required, but that could be fixed in the future with Incremental Consent.
Then assuming you are using our authentication libraries which automatically caches the access tokens, when the user opens the second application, they will not be prompted to consent because you already have a token cached for that Application ID.
This obviously is not the best solution, but one that has been used in the past for large enterprise applications.
I'm quite familiar with OAuth 2 for other providers, but haven't used it for Instagram before.
Like many developers, I have multiple domains where my app may run, eg:
http://www.foo.com/oauth2callback
https://www.foo.com/oauth2callback
http://localhost:3000/oauth2callback
https://localhost:3000/oauth2callback
Other OAuth 2 providers I have used, eg, Google, allow multiple entries in a redirect_uris parameter.
However Instagram only seems to allow a single Redirect URI parameter per registered app.
Can I have multiple redirect URIs for a single Instagram app or do I have to register multiple apps, each with a different redirect URI?
With Instagram apps that I have created, I have created a separate app per place I want to redirect to, although I haven't discriminated by ssl. I then load the api credentials into the app based on the environment it is running in.
It is a pain that you have to do that, as Instagram also restrict you to 5 registered apps per account too. It would be useful to be able register multiple redirects for that reason. But on the other hand, it would be just as good, for me, to not be restricted to the number of apps you can create (I've got more Twitter apps than I even remember creating!).
It looks like now you can set multiple Redirect URL(s) when you register/edit a Client in Instagram:
I think this is one of those scenarios that you feel back in the Atari.
anyway, I found useful doing this one:
edit your hosts file (in unix based OS: /etc/hosts)
make sure you add a line like this:
127.0.0.1 registeredomain.com
Where registeredomain.com is the domain you have in instagram as your production return uri.
In this way your app will return uri to registeredomain.com that is equivalent to localhost in your local machine, accepting the login.
btw: why? why? why? why instagram, why you have to force one return uri? any reason for that?
I'm using dotNetOpenAuth to provide SSO to my app via a user's Google Apps account. Besides just simple authentication I also ask Google to return the user's email, first name and last name. When a user first goes in they get redirected to the typical Google Accounts page telling them that the app is asking for this info and do they want to allow it. There is the checkbox there to Remember This Approval. The problem is, the approval isn't being remembered. It does remember them if they go back to the site without closing their browser. But if they close their browser and then open it later and go back in, they are again prompted to allow it.
If I look through my Google account page that shows me connected sites, apps, and services, I see my app listed multiple times. It's like it doesn't recognize that it's the same app and keeps adding it.
I know I must be missing something obvious, but I'm not sure what it is. Any ideas?
Thanks!
You can find my code here
I see several problems in your code. To first answer your direct question, the reason Google doesn't remember you on return visits is because you are passing a random GUID in as part of your Realm each time you log in. The symptom is actually much worse than you realize. It's not just that Google prompts the user on return visits, your site won't recognize the user at all on return visits because Google will give them a new claimed identifier on each visit.
The fix is that you should use the exact same Realm for every login request:
Realm realm = "http://www.yoursite.com/";
var req = openid.CreateRequest(discoveryUri, realm, URIbuilder.Uri );
Or my personal favorite:
var req = openid.CreateRequest(discoveryUri, Realm.AutoDetect, URIbuilder.Uri );
Realm.AutoDetect will work for you unless your site is available both via HTTP and HTTPS, in which case you need to lock it down to just one or the other of these so that Google recognizes your site as always the same.
You must also remember that the returnTo URL that you pass in as the 3rd parameter to CreateRequest must always be based on the realm. So if your realm is HTTPS, so must your returnTo parameter be.
I also want to call out that you seem to have some GUID code and complex URL manipulation around trying to ensure that every OpenID response you accept comes from a request you sent out. I'm not sure why you're trying to do this in the first place, although there certainly can be legitimate reasons. The way you did it is insecure and can be circumvented. I suggest you delete all this code, in favor of adding this to your web.config file:
<dotNetOpenAuth>
<openid>
<relyingParty>
<security rejectUnsolicitedAssertions="true" />
</relyingParty>
</openid>
</dotNetOpenAuth>
The library has support for requiring all responses to come from your requests built in, and it does so securely so that the security exploit I alluded to earlier isn't possible.
But if you're only trying to apply this restriction so that you know it's coming from Google, may I recommend that instead of rejecting unsolicited assertions, you instead check the IAuthenticationResponse.Provider.Uri property when you receive responses and verify that it is coming from the Google OP Endpoint? Then, if Google ever supported sending unsolicited assertions it would work on your site, and ultimately your security gate is exactly where you intended it to be anyway.
I'm trying to write a web application that would use Twitter via OAuth.
I run my local server as 'localhost', so I need the callback URL to be something like http://localhost/something/twitter.do but Twitter doesn't like that: Not a valid URL format
I'm probably going to do a lot of tests, but once I've approved my app with my username, I can't test again can I? Am I supposed to create multiple twitter accounts? Or can you remove an app and do it again?
You can use 127.0.0.1 instead of localhost.
You can authorize your app as many times as you like from the same twitter account without the necessity to revoke it. However, the authenticate action will only prompt for Allow/Deny once and all subsequent authenticate requests will just pass through until you revoke the privilege.
Twitter's "rate limiting" for API GET calls is based on IP address of the caller. So, you can test your app from your server, using the same IP address, and get (once approved) 15,000 API calls per hour. That means you can pound on your app with many different usernames, as long as your approved IP address remains the same.
When you send the e-mail to Twitter to ask for an increase to your rate limit, you can also ask for the increase to apply to your Twitter username too.
I believe Twitter requires you - if you need to change your IP address, or change the username that is using the app - to send in another request asking for the rate limit increase for that new IP address or username. But, in my experience, Twitter has been pretty quick at turning around these requests (maybe less than 48 hours?).
use like this
for Website :http://127.0.0.1
and for callback URL: http://127.0.0.1/home
or any of your page address like http://127.0.0.1/index
Have you tried creating your own caching mechanism? You can take the result of an initial query, cache it on thread local, and given an expiration time, refresh from Twitter. This would allow you to test your app against Twitter data without incurring call penalties.
There is also another solution (a workaround, rather) which requires you to edit your hosts file.
Here is how you do it on a linux box:
Open your /etc/hosts file as root. To do this, you can open a terminal and type something like sudo vi /etc/hosts.
Pick a non-existent domain to use as your local address, and add it to your hosts file. For example, you will need to add something similar to the following at the end.
127.0.0.1 localhost.cep # this domain name was accepted.
So, that's pretty much it. Pointing your browser to localhost.cep will now take you to your local server. Hope that helped :)
In answer to (1), see this thread, in particular episod's replies: https://dev.twitter.com/discussions/5749
It doesn't matter what callback URL you put in your app's management page on dev.twitter.com (as long as you don't use localhost). You provide the 'real' callback URL as part of your request for an OAuth token.
1.) Don't use localhost. That's not helpful. Why not stand up another server instance or get a testing vm slice from slicehost?
2.) You probably want a bunch of different user accounts and a couple different OAuth key/secret credentials for testing.
You were on the right track though: DO test revoking the app's credentials via your twitter account's connections setting. That should happen gracefully. You might want to store a status value alongside the access token information, so you can mark tokens as revoked.