DotnetNuke redirect - redirect

our client needs to shortcuts to particular pages
We need to redirect non existent urls like
http://site.com/promotion1
to the actual URL similar to
http://site.com/promotions/promotion1/tabid/799/language/en-AU/Default.aspx
...
I've sent a list of appropriate DNN modules to our client but it may take them forever to get back to me.
In the mean time they still submitting requests to us to create redirects for them.
if there's no cost involved then i wont have to wait for them to get back to me.
so I'm looking for a Quick and free way to enable the clients to set these up on this own.
I've looked at:
MAS.ActionRedirect
Ventrian Friendly URL Provider
DotNetNuke URL Rewriting HTTP Module
But haven't had much luck in the small amount of time i have available.
Has anyone got some suggestions on how to achieve our goal with either the above resources or maybe some additional resource i haven't found yet?
(DNN v4.9)

You should be able to use the built-in friendly URL functionality within DNN, or use a URL rewriter module within IIS.
You can read my answer about using the DNN Friendly URL functionality for more details, or look into the IIS URL Rewrite module.

Related

How to protect a public accessible API?

I'm working in creating a FORM (kind of survey) to get user input, any user who visited the website can provide me information. This would means, the API is actually public accessible to anyone without any token or session (basically nothing)
I want to prevent people from getting my endpoint and create thousand/millions of requests (SPAM) to flood my service and database. I've tried to look over Stackoverflow and some post in medium, it's interesting that I don't find much about this.
Some said:
bundle my website as an hybrid app, supply accessToken to only "trusted device" for firing my api (but this is a pure webapp)
creating custom header and identify the header from my web server (hmm..?)
use CAPTCHA (this will only stop people spamming via the GUI, but spamming via script still possible)
Is this simply no better way to secure, since it's public?
Any thoughts to share?
have you read about Request Queue?
it might help you solve the issue
source 1
source 2

Embedding HTTP response into Confluence without HTML Macro

Context: The HTML Macro is disabled on my company's Confluence.
Use-case: Embed content returned by an internal web-site.
Example: We have a table that lists various sites we have deployed. We have a Confluence page, with a table describing each, and with a URL to each.
Each site also supports a "/ping" that tells us it is live. Is there a way to embed the (simple textual) response from that ping as another column, without the use of HTML Macro?
Stretch goal: If our REST /ping returns Markup/Markdown ...is there a way to get some minimal formatting?
I am working on sth similar as well that calls a public rest api to aggregate some results on a confluence page.
Anyways, I am guessing the html macro is disabled in your company for security reasons. Since you have a specific rest api endpoints, I would suggest that you can create your own custom plugin with a macro. Design it so that the macro can take a param to know which site endpoint to call server side. You can process your requests and let the macro return a string which you can stylize however you want. This is the simplest and cheapest solution (since you won't be paying license fees for a third party addon), and also most secure since you have control over the code.
Is your confluence instance server or cloud? Have you tried asking in the atlassian community forums?
if your company can disable the free alternative then
use the paid alternative : adaptavist scriptrunner
script macro

How to make initial request for nested resource from self describing REST API

Background:
I have a single page application that pulls data from a REST API. The API is designed such that the only URL necessary is the API root, ie https://example.com/api which provides URLs for other resources so that the client doesn't need to have any knowledge of how they are constructed.
API Design
The API has three main classes of data:
Module: Top level container
Category: A sub-container in a specific module
Resource: An item in a category
SPA Design
The app consuming the API has views for listing modules, viewing a particular module's details, and viewing a particular resource. The way the app works is it keeps all loaded data in a store. This store is persistent until the page is closed/refreshed.
The Problem:
My question is, if the user has navigated to a resource's detail view (example.com/resources/1/) and then they refresh the page, how do I load that particular resource without knowing its URL for the API?
Potential Solutions:
Hardcode URLs
Hardcoding the URLs would be fairly straightforward since I control both the API and the client, but I would really prefer to stick to a self describing API where the client doesn't need to know about the URLs.
Recursive Fetch
I could fetch the data recursively. For example, if the user requests a Resource with a particular ID, I could perform the following steps.
Fetch all the modules.
For each module, fetch its categories
Find the category that contains the requested resource and fetch the requested resource's details.
My concern with this is that I would be making a lot of unnecessary requests. If we have 100 modules but the user is only ever going to view 1 of them, we still make 100 requests to get the categories in each module.
Descriptive URLs
If I nested URLs like example.com/modules/123/categories/456/resources/789/, then I could do 3 simple lookups since I could avoid searching through the received data. The issue with this approach is that the URLs quickly become unwieldy, especially if I also wanted to include a slug for each resource. However, since this approach allows me to avoid hardcoding URLs and avoid making unnecessary network requests, it is currently my preferred option.
Notes:
I control both the client application and the API, so I can make changes in either place.
I am open to redesigning the API if necessary
Any ideas for how to address this issue would by greatly appreciated.
Expanding on my comment in an answer.
I think this is a very common problem and one I've struggled with myself. I don't think Nicholas Shanks's answer truly solves this.
This section in particular I take some issues with:
The user reloading example.com/resources/1/ is simply re-affirming the current application state, and the client does not need to do any API traversal to get back here.
Your client application should know the current URL, but that URL is saved on the client machine (in RAM, or disk cache, or a history file, etc.)
The implication I take from this, is that urls on your application are only valid for the life-time of the history file or disk cache, and cannot be shared with other users.
If that is good enough for your use-case, then this is probably the simplest, but I feel that there's a lot of cases where this is not true. The most obvious one indeed being the ability to share urls from the frontend-application.
To solve this, I would sum the issue up as:
You need to be able to statelessly map a url from a frontend to an API
The simplest, but incorrect way might simply be to map a API url such as:
http://api.example.org/resources/1
Directly to url such as:
http://frontend.example.org/resources/1
The issue I have with this, is that there's an implication that /resource/1 is taken from the frontend url and just added on to the api url. This is not something we're supposed to do, because it means we can't really evolve this api. If the server decides to link to a different server for example, the urls break.
Another option is that you generate uris such as:
http://frontend.example.org/http://api.example.org/resources/1
http://frontend.example.org/?uri=http://api.example.org/resources/1
I personally don't think this is too crazy. It does mean that the frontend needs to be able to load that uri and figure out what 'view' to load for the backend uri.
A third possibility is that you add another api that can:
Generate short strings that the frontend can use as unique ids (http://frontend.example.org/[short-string])
This api would return some document to the frontend that informs what view to load and what the (last known) API uri was.
None of these ideas sound super great to me. I want a better solution to this problem, but these are things I came up with as I was contemplating this.
Super curious if there's better ideas out there!
The current URL that the user is viewing, and the steps it took to get to the current place, are both application state (in the HATEOAS sense).
The user reloading example.com/resources/1/ is simply re-affirming the current application state, and the client does not need to do any API traversal to get back here.
Your client application should know the current URL, but that URL is saved on the client machine (in RAM, or disk cache, or a history file, etc.)
The starting point of the API is (well, can be) compiled-in to your client. Commpiled-in URLs are what couple the client to the server, not URLs that the user has visited during use of the client, including the current URL.
Your question, "For example, if the user requests a Resource with a particular ID", indicates that you have not grasped the decoupling that HATEOAS provides.
The user NEVER asks for a resource with such-and-such an ID. The user can click a link to get a query form, and then the server provides a form that generates requests to /collection/{id}. (In HTML, this is only possible for query strings, not path components, but other hypermedia formats don't have this limitation).
When the user submits the form with the ID number in the field, the client can build the request URL from the data supplied by the server+user.

X-FRAME-OPTIONS allow-from a top-level domain, and all subsequent sub-domains

I'm in a conundrum, and could really use some help...
I'm having difficulty trying to find information regarding how to enable a site -that already has X-FRAME-OPTIONS: SAMEORIGIN encoded- to be loaded into an iframe from a couple of specific domains (i.e. domain.com would be the common TLD). The issue is, that although this would be quite simple to do -using X-FRAME-OPTIONS: ALLOW-FROM http://domain.com-, if that were the only domain which would ever have a need to access the target site via an iframe. In reality however, I actually need to figure out how to set it up for (currently) three sub-domains -with the possibility of allowing from even more in the future- of the original TLD (i.e. example1.domain.com, example2.domain.com, and example3.domain.com), to be able to access the site while loaded inside the intended iframe. The only info I've been able to find regarding this issue so far is quite a bit outdated, and says that there is NO POSSIBLE WAY to allow a wildcard reference (or any other form of multiple domain reference) for a particular domain that would also apply to it's subsequent sub-domains (or anything along those lines) that seems to be effective at both functioning as intended and also preventing 'Clickjackin' by malicious individuals from occurring. I was hoping that someone more knowledgeable (and better versed in X-FRAME-OPTIONS) than myself might actually be able to offer me a feasible resolution.
Thanks in advance.
If you can entertain approaches outside of X-Frame-Options, consider creating a server-to-server API that can be called to access the content in question, and then allow it to be displayed without requiring framing.
That is, instead of ClientSite containing an IFRAME referencing the FramedPage which does the page assembly within the web browser, ClientSite calls an API on the backend to get the content directly from you and inserts the content into the page on the server before delivering the page to the user's web browser.
This gives you substantial flexibility. You could require an API key, apply basic server-to-server IP address whitelisting, or whatever suits, to prevent unwanted callers of your API.

How can one learn to use the twitter API?

Ok before you jump to some conclusion like I'm looking for a free lunch or something of the sort, read the description entirely.
I have experience only in making small simple apps in PHP, Java and ASP.NET. I had no idea what GET, SET etc exactly are and what REST services are. To try to use the Twitter API, I did some reading and got to know (I might be wrong here, because this is what I THINK that I know..) that you can make a GET request like this one:
http://api.twitter.com/1/statuses/user_timeline.json
Using, say, cURL (I haven't tried it yet), and you get a JSON object returned which contains the statuses on your timeline in a certain format. And I verified this from here
But I don't understand how does Twitter know that it is ME and return only MY data? Where am I sending my account details?
What I want is for the use to come to my website, click a button to give my application the permission to access his/her Tweets and I do some processing in PHP and display the output. But I don't know where do I start from?
I am not asking you to give me bread, I'm asking you to tell me what should I do to learn to fish?
All tutorial I have been following till now have been sort of spoon fed where they say things like 'Download this php file from our site, include it in your source file, use this method to do this and that method to do that.'
This one is a change for me, so does anyone have any pointers? Is there any reading that I should do or approach that I must follow to learn that I'm doing wrong?
EDIT : I know there are 3rd party libraries out there and it might be easier to learn to use those, but I want to have an idea of how the people who made those did it.
To use Twitter (at least its REST API), you had better to read tutorials about the following things :
REST architecture because it is how Twitter communicates with your application.
HTTP requests. Useful for Authentication of requests (HTTP headers), kinds of HTTP requests (GET and POST for the Twitter API) and return codes of requests.
OAuth which is the protocol used by Twitter for authenticating requests.
Format of datas returned by Twitter after the requests. Most of the time it is JSON but it can also be like in a URL query string (for OAuth authentications). You are lucky because before there were XML and Atom (for RSS feeds) too.
And of course the Twitter Documentation to know how they use all that stuff, how they know that is YOU with THIS application (request authentications) and to know the objects manipulated by the API (mainly tweets, users and timelines).
Good luck for it !