my app had been removed on play store cause
REASON FOR SUSPENSION: Violation of the dangerous products provision of the Content Policy:
We don't allow content that harms, interferes with the operation of, or accesses in an unauthorized manner, networks, servers, or other infrastructure.
After a regular review, we have determined that your app has a malformed AndroidManifest.xml file which may make it difficult for users to uninstall the app.
In particular, the app’s AndroidManifest.xml contains a malformed Device Admin receiver entry (as identified by meta-data named android.app.device_admin). To be a well-formed Device Admin, the entry must declare an Intent filter for Intents with action android.app.action.DEVICE_ADMIN_ENABLED. The suggested modification is to make the entry well-formed if the receiver is a Device Admin, or remove the meta-data named android.app.device_admin if the receiver is not a Device Admin.
This particular app has been disabled as a policy strike. If your developer account is still in good standing, you may revise and upload a policy compliant version of this application as a new package name.
I still dont understand why they removed it,
i using in manifest is same with other app in play store,
could anyone help me know why may app had removed :S, so sad
So is it possible to create such a method without a violation of the terms?
<receiver
android:name=".DeviceAdminDemoReceiver"
android:permission="android.permission.BIND_DEVICE_ADMIN" >
<intent-filter>
<!-- This action is required -->
<action android:name="android.app.action.DEVICE_ADMIN_ENABLED" />
</intent-filter>
<!-- This is required this receiver to become device admin component. -->
<meta-data
android:name="android.app.device_admin"
android:resource="#xml/uses_policies" />
</receiver>
Related
In fact i have a django web app that i host in continous deployment. When i try to open this app in chrome i have a warning red page which notice that the site is fraudulent and in addition i have to enabled the chrome advance protection to be protect of malicious site. In the show more button i can access the site by clicking on open the insecure site. Trying to open the site in edge browser i didn't see any kind of warning and the site open successfully. By this point i think that it's something relative to the security settings of chrome.
bellow is the error:
*fraudulent website
Attackers at xxxxxxxxxxx might trick you into doing something dangerous, like installing software or revealing your personal information (for example, passwords, phone numbers, or credit cards). know more
To use Chrome's highest level of security, enable enhanced protection
Recently, Google's "Safe Browsing" feature detected phishing from bluecamp.azurewebsites.net. Phishing sites pretend to be other sites to trick you.
*
You can report a detection issue or, if you understand the risks to your security, access this unsafe site.
Then i navigate to the security settings of chrome and disabled the protection settings to without security and by this point the site log without the previous error. The issue is i have to deploy the site and no matter the browser, the site should open without any kind of error. I was also thinking that it's something relative to my django apps secret key and i generate another using the django apps secret key generator but no change.Any kind of hand to solve this problem will be thankfull.
I am working on Sitecore Item Web Api, I have a mulitisite solution and I want to give access of Sitecore Item web api to specific Site as per sitecore user.
For example, I have a demo site and have specific user for this site:
uname - test
pass - test123
My requirement is this user only can access given site via api not others Is it possible and how?
I am using http://sdn.sitecore.net/upload/sdn5/modules/sitecore%20item%20web%20api/sitecore_item_web_api_developer_guide_sc66-71-a4.pdf document and on page 13 it shows some extra fields for security "Field Remote Read" but in normal solution it's not showing any field like this
If you cannot see the field from the column list like #nsgocev stated, make sure that "Sitecore.ItemWebApi.config" is present in your include folder and enabled. This config adds the remote:fieldread field to the access rights/security editor.
<accessRights>
<rights>
<add name="remote:fieldread" comment="Field Read right for remoted clients." title="Field Remote Read"/>
</rights>
...
</accessRights>
Also make sure you set the correct mode to take this field into account (as stated in the documentation) to set up the API correctly.
<site name="website">
<patch:attribute name="itemwebapi.mode">AdvancedSecurity</patch:attribute>
<patch:attribute name="itemwebapi.access">ReadOnly</patch:attribute>
<patch:attribute name="itemwebapi.allowanonymousaccess">false</patch:attribute>
</site>
To display the Field Read Remote column you should enable it from the columns options from the ribbon:
And check the checkbox there:
I'm building a lightweight web interface to SSRS where web app users are mapped to web app roles, which in turn are mapped to SSRS users.
The reason for this convoluted scheme is not up for debate: In short, AD groups can't be used, the site uses Forms auth and there are a fixed number of roles.
Web Role | SSRS User
Admin | AdminUser
Supervisor | SuperUser
User | BasicUser
Guest | GuestUser
The goal is to enumerate all reports a user has permission to view, and allow the user to view the report with the ReportViewer control.
More importantly, it's to simplify the UX for users, both admins and the rest: preventing admins from having to use the Report Manager website (ie, selecting checkboxes rather than hand-typing which web-role-users have access to which reports), and providing a simple UI from which users can see and execute all their reports.
Everything works OK when the user is the AdminUser.
However, I'm having difficulty calling the web service when the user isn't included in a Policy on the Home/Root folder with at least the Browser SSRS role. (The permissions granted to user 'computer\username' are insufficient for performing this operation.)
This is problematic for a couple reasons:
If every user must be a Browser to connect to the web service and enumerate reports they have access to view/execute, then all users will have access to all new reports/folders by default. (Children automatically inherit new permissions)
If a report exists in a nested folder that does not inherit permissions and the user is not a browser of, but the user is a Browser on the nested report, ListChildren() will not return that report.
It seems this leaves me with 2 less than ideal options:
Don't call the web service with the different users. Instead, enumerate reports with ListChildren() using only the admin user. Then, for each report, call GetPolicies(), and from that collection of policies, determine what reports the user is able to view.
Make the call with different users. Live with the pitfalls of newly-published reports being accessible to everyone by default, until permissions are changed. Also live with the pitfalls of nested reports not showing unless the user has access to that path. If an admin wants a nested report within a folder with explicit permissions to be available to a user who can't see that folder, the policies on all ancestor folders and their children must be modified.
#1 is obviously very unwieldy and inefficient. But #2 has significant drawbacks and becomes just as onerous & inefficient when setting permissions in certain situations.
Is there a better way? Have I missed something obvious?
[edit]
A 3rd option is to query the ReportServer database directly using a query like this. This has the benefit of returning everything the user has access to, regardless of whether or not it exists in a subfolder the user cannot access (aka, cannot use the web service's ListChildren method to retrieve). However, if using AD groups, I would have to know which groups the user is a member of, whereas the web service would do this for me. This option feels like a bit of a hack to me, but it could work.
As it turns out, we ran an end-route around this issue by dropping the requirement to restrict report access by web role, and made the path we query in the web service a web.config setting that can change, thus allowing report authors to 'hide' reports in a parent folder if the need arises in the future.
The best solution would have been to query the ReportServer database directly.
However, the client changed their mind & didn't want to restrict reports based on web user role in the end, so problem solved!
I'm trying to wrap my head around RESTful design, and I'd like to understand it in terms of a social network. I've read REST API Design Rulebook, looked in some other books and read a lot of online resources. Still, when applying the rules to real-world problems I realize that I don't fully understand everything. I want to know if I have the correct understanding of REST by specifying some issues:
Hierarchy vs. flat design
Let's assume that I identify a particular user with
/users/42
Now, the photos uploaded by that user would end up in
/users/42/photos
and if he/she tags his/her friends in the photo those tags would end up in
/users/42/photos/1337/tags
But this provides no way of finding all photos where a particular user is tagged. Should I come up with a different hierarchy for that? It seems a bit awkward. Am I allowed to completely disregard the hierarchy and provide photos in combination with queries like this?
/photos?owner=42
/photos?tagged=42
Caching when content differs for different users
A Web Service should be designed to provide cacheable data (so that the client could decide to use the local copy, if it thinks that nothing has been changed), but how does that affect the privacy settings for different users? Two users, both logged in, might have the rights to view different information about e.g. user 42. Does that mean that I somehow need to request different URIs for different users accessing the profile information of the same user, or will the caching not be an issue as long as the users provide different credentials?
Providing both HTML and JSON/XML from the same resource
The book I mentioned specifies the rule that an API should be accessible at a subdomain starting with api, in their example http://api.soccer.restapi.org. I had planned to use the same controller for both user access and machine access (for example a mobile app). The controller would decide on which view to provide (text/html, application/json or application/xml) through the Accept field in the HTTP request header. I take it that that would be a bad idea for some reason (since a user would expect to see the subdomain www, not api), but I don't understand why. Can www and api point to the same server, or should I really try to move the HTML view to a different virtual host? Why?
I believe Ruby on Rails will (Convention over Configuration) provide both HTML and JSON from the same controller, thus sharing my idea that HTML and JSON are just different representations of the same data.
In other words, my book says that a certain resource should have one and only one URI, and that different representations should be provided based on the Accept field. Redirecting the user between different subdomain would violate the rule about providing any representation from the same resource, and duplicating the information (i.e. pointing two subdomains to the same virtual host) violates the rule about not providing multiple URIs for the same resource. Not providing the api subdomain violates yet another design rule. How can I solve this without violating any rule?
Limiting the data sent back
The query component should be used for pagination, but am I allowed to refuse to honor listing requests lacking search criteria and limit the number of items, without violating REST? I want to both reduce the database load and avoid having someone map the entire directory of users. I want
/users
to be an illegal request, while
/users?name=leet+hacker
would be valid but only return e.g. 100 items.
I also wonder if it's legal to return a subset of the database columns and more/all of them only if they're specifically requested using a query.
Controllers providing redundant data
I believe it's legal to provide a controller like
/users/me
but should it provide the exact same information as the document URI
/users/42
or should it redirect to it?
Extended rights for some users
Which is the RESTful way to provide additional functionality, for example administration rights? I'm now assuming that an administrator (of a photo, of a group of users or of the entire site) will be able to see more information about a particular object than other users. Should that information be kept at exactly the same URI and be sent automatically to the administrator but not to anyone else, should it be stored at a different location, should it be requested using a certain administrator query or provided in some other way?
Localization and settings updates
Although the majority of strings visible to the user should be provided by the view, there are some design decisions that might involve the API. The most obvious are names. Social networks sometimes allow the user to enter different names that are to be displayed in different language contexts. Names in some languages, like Russian and Arabic, are not easily transcribed automatically. In other languages, like Chinese, the local and international names can be completely different, with no resemblance or connection at all. What would be the RESTful way of handling this? I have a feeling that the answer will be the Accept-Language field, but is anyone seriously considering that for switching languages on the social network they belong to? Should all this information be returned to the caller every time, or can I rely on the settings? Will that work with a cache?
As #Mark Dickinson mentioned, there are a lot of questions here, which really should be separate, but I'll do my best.
Hierarchy vs. flat design
There is nothing in REST suggesting you cannot have multiple parallel hierarchies (though I understand that doing so with Rails is awkward). Having /users/42/photos/owner and /photos/owner/42 containing the same set is fine. Similarly /users/42/photos/tagged and /photos/tagged/42 can contain the same set. However, you shouldn't be worried about the URIs at this time. There is an excellent article A RESTful Hypermedia API in Three Easy Steps that describes how to design your API. In this article, the URIs are decided as the last step.
Also, using the HATEOAS contstraint, these various URIs should be discovered at runtime by the client, through the links and forms provided by your application.
Caching when content differs for different users
If you are going to serve different content from the same URL, then it's not going to be cacheable. You can partition you site into two types of content, public and personalised. The public content should be the same for everyone and can be cached. The personalised content is different for each user, which means that the amount you can cache it will be dramatically reduced (reduced to zero using the URL format you have used in your examples).
To get at least a small amount of caching on personalised content, partition the content by the user, so that for a give user you'll get some cache hits. For example, instead of having /users/42 that everyone can access, use /<UID>/users/42 where is the userid of the requesting user. e.g. user 234 would access the profile page for user 42 using the URI /234/users/42. For anonymous users you could either remove the /<UID part or use a specific userid for them, such as /public/users/42.
Providing both HTML and JSON/XML from the same resource
Use the Accept header. That is what it is there for.
Limiting the data sent back
You don't need to make /users an illegal request. Treat is a a collection and return a paginated list of users that the requester is permitted to see. For example for an anonymous request you might provide an empty list (or 204 No Content)
<users/>
and for a particular logged in user, you might provide their friends.
<users>
<user id="42" href="/users/42" name="John Doe"/>
<user id="53" href="/users/53" name="Jane Doe"/>
...
<next href="/users?page=2"/>
</users>
when that user then GETs /users?page=2 you would then provide the next page of results
<users>
<user id="69" href="/users/69" name="John Smo"/>
<user id="84" href="/users/84" name="Jane Smo"/>
...
<next href="/users?page=3"/>
<prev href="/users"/>
</users>
With the last page of results providing no next link. To add a searching capability, you just add an appropriate form as part of the response.
<users>
<user id="69" href="/users/69" name="John Smo"/>
<user id="84" href="/users/84" name="Jane Smo"/>
...
<next href="/users?page=2"/>
<prev href="/users"/>
<search href="/users" method="get">
<name cardinality="required" type="regex"/>
</search>
</users>
The results of the search would be paginated, just like the /users list. e.g., searching for leet hacker (Assuming you have permission to view a lot of leet hackers in the system) would produce something like
<users>
<user id="234" href="/users/234" name="leet hacker"/>
<user id="999" href="/users/999" name="leet hacker"/>
...
<next href="/users?name=leet+hacker&page=2"/>
<search href="/users" method="get">
<name cardinality="required" type="regex"/>
</search>
</users>
however you will probably need to provide more details in the user element, so the leet hackers can be differentiated.
Controllers providing redundant data
Both are acceptable. However as above (for caching reasons) I would use /<UID>/users/42, in which case you might want to redirect /42/users/me to /42/users/42.
This also helps from an analytics point of view as you might want to separately track a users access the their own page, from users access to other users page, to find out which users are popular and which are narcissistic. You may even find a correlation between the two :)
Extended rights for some users
Provide the admin links and forms in the appropriate response. For instance, accessing details of someone else's image might provide
<image id="266" href="/photos/266" caption="leet hacker with computer"
src="http://us.123rf.com/400wm/400/400/creatista/creatista0911/creatista091100003/5827629.jpg"/>
<tagged-users>
<user id="234" href="/users/234" name="leet hacker"/>
</tagged-users>
<owner id="234" href="/users/234" name="leet hacker"/>
</image>
but for the image owner, it might provide
<image id="266" href="/photos/266" caption="leet hacker with computer"
src="http://us.123rf.com/400wm/400/400/creatista/creatista0911/creatista091100003/5827629.jpg"/>
<tagged-users>
<tagged-user id="234" href="/users/234" name="leet hacker">
<delete href="/photos/266/tagged/234" method="delete"/>
</tagged-user>
<add href="/photos/266" method="put">
<user cardinality="required" type="user-id"/>
</add>
</tagged-users>
<owner id="234" href="/users/234" name="leet hacker"/>
<delete href="/photos/266" method="delete"/>
<update href="/photos/266" method="put">
<caption cardinality="optional" type="string"/>
</update>
</image>
Localization and settings updates
Use Accept-Language for the default language, but allow a user to change the language in their settings.
If you're using WCF Web Api (or even if you aren't) it might be worth your while looking at the OData support in there. It does address some of the issues of making things more searchable.
I've recently seen XSSI mentioned on multiple pages, e.g. Web Application Exploits and Defenses:
Browsers prevent pages of one domain from reading pages in other domains. But they do not prevent pages of a domain from referencing resources in other domains. In particular, they allow images to be rendered from other domains and scripts to be executed from other domains. An included script doesn't have its own security context. It runs in the security context of the page that included it. For example, if www.evil.example.com includes a script hosted on www.google.com then that script runs in the evil context not in the google context. So any user data in that script will "leak."
I fail to see what kind of security problems this creates in practice. I understand XSS and XSRF but XSSI is a little mysterious to me.
Can anybody sketch an exploit based on XSSI?
Thanks
This is typically a problem if you are using JSONP to transfer data. Consider a website consisting of a domain A that loads data from domain B. The user has to be authenticated to site A and B, and because the Same Origin Policy prevents older browsers from communicating directly with a different domain (B) than the current page (A), the developers decided to use JSONP. So site A includes a script pointing to http://B/userdata.js which is something like:
displayMySecretData({"secret":"this is very secret", ...})
So A defines a function called displayMySecretData, and when the included script from server B runs, it calls that function and displays the secret data to the user.
Now evil server E comes along. It sees that A is including data from B using JSONP. So server E includes the same script, but defines its own displayMySecretData which instead steals the data.
The attacker then tricks the user into visiting his site. When the user goes there and he is logged in to B, the browser automatically sends the authentication cookies for B along with the request to fetch the script from B. B sees an authenticated user, and thus returns the script as expected. E gets the data, and presto...
Using JSONP to load confidential data from a different domain this way is thus really insecure, but people are still using it. Bad idea!
XSSI is not limited to jsonp responses. In some browsers you can override the Array constructor. If a Json response contains [...] and you include it as a script it will execute the new constructor instead of the builtin one. The fix is to insert something in the response that can't be parsed like ])}while(1);</x> and then use code to remove it before parsing it. An attacker can't do that since script inclusion is always the entire script.
More detail on the problem and this solution at http://google-gruyere.appspot.com/part3#3__cross_site_script_inclusion
XSSI is a fancy way of saying: you are including in your program, someone elses code; You don't have any control over what is in that code, and you don't have any control over the security of the server on which it is hosted.
For example, let's say i include in my html page
<script type="text/javascript" src="http://mymatedave.com/js/coolwidget.js"></script>
That script will run in my webapp with the same level of trust as any of my own javascript code. It will have access to the the full page content and DOM, it will be able to read all my app's cookies and read the users keypresses and mouse movements, and everything else that javascript can do.
If my mate dave, then decides to put something malicious in his cool widget (say, a sniffer/keylogger that sends all the user's cookies, form data and keypresses to his server) then I won't necessarily know. Also, the security of my app now depends on the security of dave's server. If dave's server gets compromised and coolwidget.js is replaced by the attacker, i again won't necessarily know and the malicious code will run as part of my app.