Poking around the REST API, I don't see a way to get the space owner. I can get the permissions list, but it is confusing, since there are many entries (duplicates!) that don't mention an operation at all.
I'm using this Python wrapper: https://pypi.python.org/pypi/PythonConfluenceAPI. I'm not sure if that's limiting my options, but the raw REST API docs don't provide any clues.
Can you please clarify what do you mean by Space Owner? Technically, in Confluence you do have a space permissions and it doesn't have owner. However, people with Space Administrator permissions can consider as an owner in most of the use cases. I would recommend you to take look at space permissions document as well :-)
Related
When selecting topics for facebook ads, many are duplicates. If my experience with databases has taught me anything, it's that humans enter data in all sorts of ways. So I guess facebook's algorithms have found 'topics' based on how humans have entered them. So I guess duplicates could result because of a trailing space or something like that.
From the UI, I cannot tell the difference between topics which appear identical, but which may have very different followings (e.g. one may have 10m associated users, another might just have 100 if it's an uncommon typo with a trailing space).
How can I view more information on facebook 'topics'? Is there an API call for this?
Example
Here is an example of a duplicate topic
Here's where the topics can be found (requires login)
NB: as a corollary to the above, when there are duplicates (or triplets) is it beneficial to select all of them, or is selecting just one enough to maximise the effect?
You can find the solution by creating an ad from the Business Manager. Short answer is that the duplicates belong to different categories.
In your case, if you look for "Sonic drive-in", Facebook will give you the following choices (see pic):
Sonic drive-in as interest (e.g. to target those who like a related page)
Stackoverflow as an employer (to target those working there)
So, it depends on what you need for your ads.
after reading all the threads on stackoverflow and other platforms, I still wasn't able to find an answer, which satisfies me.
The task:
I want to create a single page application (SPA) which receives data from a REST API. In this SPA, NO authentication should be used. It's a public site.
But the REST API should only be accessible from people who loaded the SPA from my webserver.
I assume this is only solvable with something on server side like sessions, cookies etc. - otherwise I'm open for your suggestions, solutions etc.
Thx in advance!
There's no reasonably easy way to do this. You can easily prevent other domains (in browsers) from accessing a an API on your domain (via CORS), but it's significantly harder to prevent scripts from doing this.
The issue lies in 'how do you detect legit browser traffic from a script'. It turns out that this is not easy. You could try to detect 'unusual behavior' as much as possible (for example a large amount of requests in a short time), but this doesn't stop clients that are slower.
Ultimately if people want your data, they will find some way around whatever restrictions you come up with. You should reevaluate this and use one of the following options:
Don't do an SPA and API. Although one could wonder, if the data exists in HTML it can still be crawled.
Add authentication. But obviously this won't help you in any way if anyone can authenticate.
Re-evaluate why you have this restriction. What are you worried about? If you're worried about people taking your data and using it elsewhere, how does only showing it in a browser from 1 domain help with that? If you're worried about copyright theft, why not use a legal approach to this?
I've seen a lot of these types of questions, but in my opinion I haven't yet seen one that has a legitimate good reason to want this. But, maybe you're the first.
I believe I answered my question myself on a comment 30 minutes ago... I think with captcha I'm able to secure the REST API against unwanted access to my REST API
I would like to know what are the abilities provided when this moodle role permission 'mod/certificate:manage' if allowed for a role. Please, help. And how can i find out?
I don't have anything here https://docs.moodle.org/27/en/Capabilities/mod/certificate:manage
Is there a specific place to look for?
To get an exact idea of what that role is used for (or any other not documented one) you need to look at the code. Basically look within the directory of the mod certificate plugin for things like require_capability('mod/certificate:manage' or has_capability('mod/certificate:manage'.
In general, it is a common practice in Moodle to call manage to the capability that checks and allows for the most "manager-like" actions, the kind of actions you would allow to editing teachers and managers of a course (like, for example, manipulating settings of an instance of the activity)... but it is entirely up to the plugin developer to follow that "tradition" or not, so to look at the code is still advised.
Imagine I have a fully implemented REST API that offers HATEOAS as well.
Let's assume I browse the root and besides the self link two other links (e.g. one for /users and one for /orders) are returned. As far as I have heard, HATEOAS eliminates the need for out-of-band information. How should a client know what users means? Where are the semantics stored?
I know that is kind of a stupid question, but I really would like to know that.
Suppose you've just discovered Twitter and are using it for the very first time. In your Web browser you see a column of paragraphs with a bunch of links spread around the page. You know there's a way to do something with this, but you don't know specifically what actions are available. How do you figure out what they are?
Well, you look at the links and consider what their names mean. Some you recognize right away based on convention: As an experienced Web user, you have a pretty good idea what clicking on the "home", "search" and "sign out" links is meant to accomplish.
But other links have names you don't recognize. What does "retweet" do? What does that little star icon do?
There are basically two ways you, or anyone, will figure this out:
Through experimentation, which is to say, clicking on the links and seeing what happens, then deriving a meaning for each link from the results.
Through some source of out-of-band information, such as the online help, a tutorial found through a Google search or a friend sitting next to you explaining how the site works.
It's the same with REST APIs. (Recall that REST is intended to model the way the Web enables interaction with humans.)
Although in principle computers (or API-client developers) could deduce the semantics of link relations through experimentation, obviously this isn't practical. That leaves
Convention, based on for instance the IANA 's list of standardized link relations and their meanings.
Out-of-band information, such as API documentation.
There is nothing inconsistent in the notion of REST requiring client developers to rely on something beyond the API itself to understand the meaning of link relations. This is standard practice for humans using websites, and humans using websites is what REST models.
What REST accomplishes is removing the need for out-of-band information regarding the mechanics of interacting with the API. Going back to the Twitter example, you probably had to have somebody explain to you at some point what, exactly, the "retweet" link does. But you didn't have to know the specific URL to type in to make the retweet happen, or the ID number of the tweet you wanted to act on, or even the fact that tweets have unique IDs. The Web's design meant all this complexity was taken care of for you once you figured out which link you wanted to click.
And so it is with REST APIs. It's true that in most cases, the computer or programmer will just need to be told what each link relation means. But once they have that information, they can navigate through the entire API without needing to know anything else about the details of how it's all put together.
REST doesn't eliminate the need for out-of-band information. You still have to document your media-types. REST eliminates the need for out-of-band information in the client interaction with the API underlying protocol.
The semantics are documented by the media-type. Your API root is a resource of a media-type, let's say something like application/vnd.mycompany.dashboard.v1+json, and the documentation for that media type would explain that the link relation users leads to a collection of application/vnd.mycompany.user.v1+json related to the currently authenticated user, and orders leads to a collection of application/vnd.mycompany.order.v1+json.
The library analogy works here. When you enter a library after a book, you know how to read a book, you know how to walk to a bookshelf and pick up the book, and you know how to ask the librarian for directions. Each library may have a different layout and bookshelves may be organized differently, but as long as you know what you're looking for and you and the librarian speak the same language, you can find it. However, it's too much to expect the librarian to teach you what a book is.
Here are the two scenarios:
First one: You have a CMS you log into go to the page manager, select a template, then add a page into the system, edit the page, save it done.
Second one: You sign in, then go to the URL you want to exist but doesn't exist yet but still shows up as a template to enter in stuff. For example, "/articles/article" and since the URLs were mapped to be dynamic, the article template shows up and has the placeholders to edit right there. Different types of pages or templates would be mapped to different URL patterns such as "/product/[product-number]" etc etc.
Is there any security concerns for doing the latter since I like the second one better in terms of programming as there is no management of pages, just authentication then navigating to the desired page. The first one is more structured and is good listing them out or individiual permission settings.
Please advise.
Beyond the authentication considerations, I think both approaches are fine. I see them as ultimately accomplishing the same thing through different user experiences. To answer the question, I would paper prototype each, then pull users into a room and perform a quick / informal usability study, giving them tasks such as "create a page with ..." etc. Evaluate which model performed better. You really should answer this question by including the users that will use the system.