We Keep Coding

Using Akamai Purge API with rest assured

Just been handed the task of writing a java method to do an akamai purge. I've been through the dev docs at akamai, tried to use their community (which seems to allow new members), and things are still quite a jumble. Other than just pointing me to the Akamai site, can I get some assistance to at least get started?
I have the host (API Base URL), I have the Access Token, and I have the Content Provider Codes. What else am I missing?
Is there not just a simple REST call that can be made to perform the purge? Everything I see on the Akamai site says there is, but has no useful, simple examples. Other questions here, just refer the questioner to the Akamai dev site where they sited, or their community site where it seems registration no longer works.
So, lets say I have the following:
Host - https://akab-myhost.purge.akamaapis.net
Access Token - akab-alphanumericstuff-alphanumericstuff
Content Provider Codes -
919191 - www.thisismysite.com.pm1
919192 - www.thisismysite.com.pm2
How do I (using java) make a rest call to purge CPC 919191?
Thanks!
Greg

Have you tried api.ccu.akamai.com/ccu/v2/docs/index.html ? It gives pretty clear steps on how the REST calls are made. Also i would recommend to reconsider if you really want to purge CP Code? As this will purge everything with that CP Code. Instead i would recommend URL path or extension based Purge.
Also i would recommend to use fast purge API: https://developer.akamai.com/api/purge/ccu-v2/resources.html
Normal CCU takes ~5min to purge, where as fast purge takes less than 5sec to purge.

Allow Glassfish and PHP to work together in the same server using Apache

It's possible make a bridge from Java to php file?
I've got an application written in Java and I need execute http://piwik.org/ that is written in PHP. In the server I have PHP running but I cannot access from the browser to the php directory because all incoming traffic is redirected by apache to glassfish Application server.
So my idea is to use Java servlet to execute php files with:
Runtime.getRuntime().exec("php /path/to/file/file.php");
Then write the PHP output as java servlet response.
The only problems to accomplish this are:
How can I execute PHP cli that act like a browser?
Which parameters I need to pass to PHP to allow PHP to read or write cookie and session?

If you're using Apache anyway to proxy the traffic, I'd just exclude all traffic to Piwik and serve those directly from the file system / mod_php / php-fpm / whatever you normally use.
You could also use php-cgi and pass the appropriate environment variables, but that complicates a lot of stuff, like you'd have to proxy the response back to the browser, too. Apache has already support for this, so don't implement another proxy in your application, do it directly in Apache.
You can exclude a directory from being proxied:
ProxyPass /piwik !
ProxyPass / 127.0.0.1:8080
ProxyPassReverse / 127.0.0.1:8080

When you execute a php script from the command line the GET/POST/SESSION/COOKIE
variables are meaningless. When your file.php send a cookie there is no browser to receive it, save it and use it for subsequent requests.
What you can do is use CGI SAPI, so that all HTTP_* variables will be usable, and the headers will be written to the output.
The php-cgi binary implements the CGI interface, which allows you to pass cookies on the command line like this:
HTTP_COOKIE='PHPSESSID=XXXX' php-cgi /path/to/file/file.php
Where XXXX can be the session id of an user. You can read the cookie analyzing the headers on the output.

Thanks to the idea of kelunik to use Apache to exclude the traffic and the help By Federico I've resolved the problem using this Apache rule:
ProxyPass /phpdir !
ProxyPass / 127.0.0.1:8080
ProxyPassReverse / 127.0.0.1:8080
Apache redirect all request to port 8080, except the folder /phpdir. Into the Apache document root I've created the directory phpdir that is the new root where the PHP applications will be run.
That's it

Hadoop Java Client API messes up my fsURI

I try to access HDFS in Hadoop Sandbox with the help of Java API from a Spring Boot application. To specify the URI to access the filesystem by I use a configuration parameter spring.hadoop.fsUri. HDFS itself is protected by Apache Knox (which to me should act just as a proxy that handles authentication). So if I call the proxy URI with curl, I use the exact same semantics as I would use without Apache Knox. Example:
curl -k -u guest:guest-password https://sandbox.hortonworks.com:8443/gateway/knox_sample/webhdfs/v1?op=GETFILESTATUS
Problem is that I can't access this gateway using the Hadoop client library. Root URL in the configuration parameter is:
spring.hadoop.fsUri=swebhdfs://sandbox.hortonworks.com:8443/gateway/knox_sample/webhdfs/v1
All the requests get Error 404 and the problem why is visible from the logs:
2015-11-19 16:42:15.058 TRACE 26476 --- [nio-8090-exec-9] o.a.hadoop.hdfs.web.WebHdfsFileSystem : url=https://sandbox.hortonworks.com:8443/webhdfs/v1/?op=GETFILESTATUS&user.name=tarmo
It destroys my originally provided fsURI. If I debugged what happens in the internals of Hadoop API, I see that it takes only the domain part sandbox.hortonworks.com:8443 and appends /webhdfs/v1/ to it from a constant. So whatever my original URI is, at the end it will be https://my-provided-hostname/webhdfs/v1. I understand that it might have something to do with the swebhdfs:// beginning but I can't use https:// directly because in that case an exception will be thrown how there is no such filesystem as https.
Googling this, I found an old mailing list thread where someone had the same problem, but no one ever answered the poster.
Does anyone know what can be done to solve this problem?

I apologize for being so late in this response.
You may be able to leverage the Apache Knox Default Topology URL. In your description, you happen to be using a topology called knox_sample. In order to access that topology as the "Default Topology", you would have to configure it as the default topology name. See: http://knox.apache.org/books/knox-0-7-0/user-guide.html#Default+Topology+URLs
The default "Default Topology" name is sandbox

NRPE Protocol description

I need to query a nrpe nagios server from a Java application remotely just as check_nrpe would do:
check_nrpe -H 192.***.***.*** -p 56** -c "check_load"
When I say "from a Java application" I mean I want the results to be received and processed at my Java application. The first idea I had was to call the "check_nrpe" command from my application and retrieve its output and return value but I would like more a standalone solution where no external programs are called.
I don't need to wait for state changes, just eventually check the monitor state. Since I have been unable to locate any Java library (should I try JNRPE?), I would like to implement the protocol check_nrpe and nrpe daemon use to communicate.
Have any of you tried this before? In that case, do you have a description of this protocol?
If your answers are negative I will try to analize the protocol using whireshark but any clue will be much appreciated.

An explanation of NRPE protocol from Andreas Marschke blog, The NRPE Protocol explained (on gitHub too)
Anyway, JNRPE have a full working implementation of the protocol, you can download jcheck_nrpe-2.0.3-RC5 source code and take a look at jcheck_nrpe-2.0.3-RC5\src\main\java\it\jnrpe\client\JNRPEClient.java class for a sample client who's using jnrpe-lib-1.0.1-RC5.
jnrpe-lib have two concrete classes which implements the protocol request and response
JNRPERequest.java
JNRPEResponse.java
The full protocol implementation classes can be found at jnrpe-lib-1.0.1-RC5\src\main\java\it\jnrpe\net\ folder

Do Applets use Browser for HTTP Requests?

Is there any interaction between applets and their hosting browser when making HTTP requests, or are requests made completely independently of native browser code?
Specifically, do Java applets running in a browser have some implicit way of sharing the browser's session state and cache?
I've read a few posts from non-authoritative sources saying that when an applet makes an HTTP request that it will use the browser's cache, and that it will also have access (somehow) to the browser's cookies.
Tests I've done using URLConnection suggest that this is not the case, and my gut feeling is that it sounds far too convenient to be true. I would assume that nothing in the JVM knows anything about the world outside of that JVM, meaning the only other way this could work would be if the JVM implementation is specific to the browser its implementation of the URL-related methods delegate to native browser code?
If cookie data is not implicitly shared or available, is best practice to pass a session ID in a param tag to the applet? Are there security concerns with this approach? If the applet doesn't use the browser's cache for requests, how does caching requests in an applet work?

Applets are executed by the Java Plugin, which is a browser plugin. The applet is indeed part of an HTML page loaded by the browser, can communicate with the browser DOM and with JavaScript code in the page, and uses the browser to send requests to its originating server.
See http://docs.oracle.com/javase/tutorial/deployment/applet/appletExecutionEnv.html and http://docs.oracle.com/javase/tutorial/deployment/applet/server.html for more information.

My testing with Windows 7, Java 1.6.23 and Firefox, Chrome and Internet Explorer is that HttpURLConnections from within an applet's JVM interact in no way with the browser. They don't use the cache, and don't have cookie headers added.

I think it depends on the Java plugin. My experience is that usually it uses the browser cache for network connections, and usually it transmits the cookies. I have had to empty the browser cache before to get a new file in an applet.
If you look at the Oracle Java 7 Plugin Control Panel, you will see an option in the network parameters to use direct connections for the applets, but the default is to use "browser parameters".
As for the cookies, I have seen in the past some Java plugins that did not transmit the session cookies, in particular on MacOS X (Apple even suggested a workaround). But most developers now assume that they are transmitted, and in practice it usually works.

Applets do not share the session information by default, but you can pass the session ID via Applet parameter while initializing. And use the session ID for each HTTP request.

Applets can interact with the browser to make HTTP requests via JavaScript calls.
If you use any Java HTTP APIs e.g. UrlConnection, Apache HTTPClient, java.net.Socket these libraries will not interact with the browser. They behave as if they were in a standalone JVM.
Caching id depenednt onthe API you use, Apache HttpClient has a cache. URLConnection lets you write your own cache easy enough.
You can not directly access the existing cache in JavaScript yet, its comming tho. https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage.
A param tag can not change once the page is rendered, e.g. OAuth tokens need refreshing periodically.
You could fetch cookies from the browser via JavaScript and manually add them to a Java initiated HTTP request. This mechanism allows them to be updated.
There is not much added risk sharing a cookie. You would have to remove the HTTPOnly flag on the cookie if there is one.
If you are allowing Java in the browser your users are letting you do pretty much anything. Java inside the browser does have a sandbox but its worryingly easy to break out. If you can design apps without Java they will be much more secure for users.
From the point of view of the person writing the Applet, Java is secure and much more flexible than JavaScript in a Browser.