Endpoint to access sbt releases - sbt

We have a policy against caching the releases directly from GitHub for security reasons. We were relying on https://sbt-downloads.cdnedge.bluemix.net/releases to access various sbt releases and cache them internally. Unfortunately, this endpoint is no longer reachable. Is there an alternate endpoint or archive to https://github.com/sbt/sbt/releases/ ? Thanks.

Related

Google cloud platform TLS 1.0 update?

We had a 3rd party security company review our site and they came back saying we should update to TLS 1.2 but im not sure how to do so on GCP. They also said we should update our SSL ciphers to more than 112 bits not sure how to do that either. If someone knows how to fix these or has links on how that would be amazing
According to the information that you provided, you're using Apache with Cloud Functions and Firestore, please correct me if I'm wrong.
From the Google side if you have a Google Cloud Load Balancer (GCLB) with Serverless NEGs (Cloud Run, GAE, or GCF custom domains) you can define a SSL security policy to restrict the TLS versions and cipher suites used. I suggest you that before you configure your TLS version to check the SSL policies overview.
Otherwhise if you have another set up, I suggest you to check the link that #John Hanley shared with you in the comments.

Sharing oauth tokens between requests on a Paw project

I've got a Paw project for an API that uses OAuth 2. Everything works great, on a per request basis, but every request manages its own token. Is there a way to have a single OAuth 2 "manager" for each project, where each request can grab the latest token from that manager, rather than grabbing new tokens for each request?
Environment variables are a nice way to handle this. We've described this in the docs:
As you may often switch between development and production environments, or between several users, you may need to have several OAuth credentials you may apply to your Requests. You can keep those credentials in Environments, and then use them in the OAuth Header Dynamic Value.
Read more about Environments and how to use Environments as Reusable Presets (this actually is the doc article that can help you the most for that).

how to connect wordpress plugin securly to a platform

I 'm developing a WordPress plugin related to a platform i created earlier. The plugin will be needing some data from the database of that platform.
What is the best way to let the plugin to communicate with my external database without risking the security of my platform?
Write some api routes for your platform,like:
https://myPlatform/api/posts
In your wordpress plugin, request the apis of your platform.
You could use these requests packages:
https://github.com/guzzle/guzzle
You should alse do some validation while requesting your platform.
The accepted answer is good, but i would like to add a few things.
1) Always use secure channels for communication if the information is more likely to contain critical information (https).
2) Make good use of permission based Queries on the platform side and maybe on the plugin wordpress side check for the current logged in roles (if needed), if a particular role doesn't have to access a specific endpoint don't allow him both ways earlier checks can avoid unnecessary requests.
3) Try to make those request to the platform in a non-blocking way (ajax), to prevent unnecessary page load times.
4) Anticipate as much scenarios of how the platform will communicate its multiple messages and how your plugin should interpret them.

Do I need to change to Redis Cache in Azure from Nov 30 2016?

I have a single instance of a website hosted in Azure, which uses the in-role session cache. This uses some very basic calls to pass data between pages, such as Session("MustChangePassword") = "True"
Microsoft have emailed Azure customers saying that the in-role and managed caches are going to be retired, and that Azure Redis cache should be used instead:
Azure Managed Cache Service and Azure In-Role Cache to be retired November 30, 2016
As a reminder, Azure Managed Cache Service and Azure In-Role Cache service will remain available for existing customers until November 30, 2016. After this date, Managed Cache Service will be shut down, and In-Role Cache service will no longer be supported. We recommend that you migrate to Azure Redis Cache. For more information on migrating, please visit the Migrate from Managed Cache Service to Azure Redis Cache documentation webpage. For more information about the retirement, please visit the Azure Blog.
Is this going to still affect cloud services that use just one instance, or will Session data just completely break after this change is made if I don't do anything?
If I do have to change to Redis cache, I see from the supplied links that I can download it as a NuGet package and make changes to the web.config file. However, I am then unsure as to whether I'd need to make changes to the code, or whether the calls to Session("Whatever") would still work without any further changes needed.
So in summary:
1) Do I need to change to the new cache?
2) If so, what code changes do I need to make over and above configuring the new cache?
This announcement is at least one year old, if not older.
So in summary:
Do I need to change to the new cache?
If so, what code changes do I need to make over and above configuring the new cache?
To Anser your questions:
YES
Check out the documentation links you quoted.
And by the way, you cannot downlaod Azure Redis Cache as a NuGet package. What you download is Client SDK/API to work with Azure Redis Cache. Azure Redis Cache is a separate service in Azure. Which is also billed separately.
So it turns out that using a session call such as Session("MustChangePassword") = "True" is absolutely fine to still use in the case of running a single instance machine.
It may not be supported, but it still works, and I have not had to add any other kind of session management to this project.
Everything is working exactly as it was before the announcement, and continues to work after the deadline had passed.
So in summary:
1) Do I need to change to the new cache?
2) If so, what code changes do I need to make over and above configuring the new cache?
The answers to the above questions were 1) No, and 2) No changes needed.

What is HTTP-FED 1.1?

In investigating federated authentication, I've been running into a protocol alongside SAML: HTTP-FED.
Curiously, I can't find any technical documentation for this protocol.
What is it? Is it, like I suspect, a claims-based protocol for use with HTTP instead of WS- services?
HTTP-Fed appears to be a creation of a commercial vendor (Symplified). It has not been ratified by any standards bodies (that I've found) which is why you probably can't find much on it. From what I've read on their website, it appears to essentially be a fancy name for credential caching/credential replay across the internet. From their site -- http://www.symplified.com/http-federation/
"... HTTP-FED leverages the existing HTTP login mechanism at the SP.
The implication of this is that no changes to the SP (destination
application) are required and no special software is needed by SPs,
thereby reducing the effort required to federate domains."
It's not a standard so there's no info on how you'd implement it outside of buying their product. If you're looking at Web SSO for Cloud Applications, I'd stick with actual standards (SAML, OpenID, OAuth, Open ID Connect) that are designed with security in mind for this type of activity.

Resources