I want to host the Swagger UI behind the same webserver our API is running on (at least on dev and staging). Is it possible to do that without having to use Node whatsoever? I feel that it should be possible to host the static HTML, CSS and JS files but I can't see how.
This page* on Github suggests that swagger-ui-dist is designed for this scenario but the related page** doesn't really explain how to implement it but seems to show that Node is still required anyway.
I find the docs quite confusing.
*https://github.com/swagger-api/swagger-ui
**https://www.npmjs.com/package/swagger-ui-dist
I just worked it out. All the static files I require are in the dist directory.
Related
I can not figure out how to make nuxt generate fully static website. It makes api call static and that is awesome. But all images, and download links still making request to a remote server.
Is it possible to generate fully static website where all links to external files(<img src="remote.jpg">, <a href="remote.pdf", background-image: url('remote.jpg')) will be downloaded and placed in local folder and then every url will be replaced to local files? Or nuxt does SSG only for APIs?
You could totally optimize and put all of your assets into the /static directory indeed.
It will require some CI or any kind of build step to have them properly updated, organized etc but nothing impossible (this will keep everything in the same place). Meanwhile, having resources outside of your server is not bad in the principle itself neither.
I have a WebCenter Sites installation. Separately, I have site.js and site.css files. How can I make a WebCenter Sites template use these two files? Where do i put those files so they can be consumed?
What I've done so far is set up a simple HTTP server outside of WebCenter Sites and used <link> and <script> tags to point to those files on the external server. This does indeed work, but I prefer having the files served from the sites application.
I see sites exposes a CSS type asset, but it seems to be tied to their widget framework. I was thinking to just make an empty widget with CSS, then I could reference the widget/asset in the <link href=. Again there aren't many examples of this online.
Can anyone give me some ideas on how to serve files from within WebCenter Sites?
There are alternatives to storing files directly in the webapp, such as using a custom basic assettype to contain the files, and then delivering them via blobserver (or just rendering inline). The advantage to this is that you are managing assets to keep environments in sync, rather than updating the webapp & redeploying.
The path needs to be relative to the web application context. There are probably better ways to reference it in Sites, but the lowest-common denominator approach that will work for all J2EE web applications is to use pageContext.request.contextPath, so the link would look like:
href="${pageContext.request.contextPath}/src/stylesheets/css/styles.css"
So if this were used with a JSK, the src folder would be under [JSK_HOME]\App_Server\apache-tomcat-7.0.42\Sites\webapps\cs
I use Play framework 1.2.x
I use PDF module renderPDF to generate PDF from HTML. I would like insert a image into the PDF.
Im trying to download image from controller downloading in the HTML which will be render as PDF as like this
<img src="#{AwardController.getSignature()}">
From the forums I found that we need to define play.pool in application.conf, So I defined it and works well in local environment. But It doesn't work in QA or Prod environment where we have two processors, so I thought it would take nbprocessors+1. I tried both defining play.pool and not defining. But there is no luck in QA/Prod environment. Please help me to resolve
UPDATE: It working when http request, but not works in https request. Do we have any settings anywhere to resolved this
Folks:
I'm creating an app using Node Webkit. The purpose of this app is to display images and pdfs. The app needs to download those files from a central repository, and cache them locally. When the app runs offline, the files should still be available, and displayed.
On the face of it, this sounds like appcache is the answer - and that indeed is where I was heading when this was a pure webapp in a browser. However, now I've discovered node-webkit, and here we are.
node-webkit's GitHub wiki states:
"However, application cache is designed for browser use, for apps using node-webkit, it's less useful than the other two method, read HTML5 Application Cache if you want to use it."
But doesn't say why.
I've also researched node.js filesystem - but that seems like a whole magnitude of complexity above what I need.
Can anyone point me in a sensible direction?
Thanks.
It has to do with the nature of App Cache itself.
You specify a manifest file that lists all the static assets required for your app to run offline. You don't have any programmatic access to the cache to add and remove files via JS.
So for a node-webkit app, it'd make more sense to fetch these files and store them in the Application Support folder (Or AppData, depending on the platform). That's where the node.js part is really useful, the file IO stuff.
I have apache VM web app running locally. It's red hat.
It's PHP based but the main page is index.html. I am able to to into sub-directories for images and such, I wanted to know if it is possible for me to gain access to the directories that contain the php code, probably just one level above the images directory. Because of index.html, it forces the load, and I am unable to see server files.
Yes there used to be a trick called dot-dot-traversal that could do this. Basically you put two dots into a URL and climb above the web root. Something like http://www.example.com/../../../../etc/shadow . Occasionally a new way to exploit the vulnerability is discovered, but mostly it is rare. Unless you're running an old server, you should be pretty safe.