CMake Primer¶
Warning
Disclaimer: This documentation is written by LLVM project contributors not anyone affiliated with the CMake project. This document may contain inaccurate terminology, phrasing, or technical details. It is provided with the best intentions.
Introduction¶
The LLVM project and many of the core projects built on LLVM build using CMake. This document aims to provide a brief overview of CMake for developers modifying LLVM projects or building their own projects on top of LLVM.
The official CMake language references is available in the cmake-language manpage and cmake-language online documentation.
10,000 ft View¶
CMake is a tool that reads script files in its own language that describe how a software project builds. As CMake evaluates the scripts it constructs an internal representation of the software project. Once the scripts have been fully processed, if there are no errors, CMake will generate build files to actually build the project. CMake supports generating build files for a variety of command line build tools as well as for popular IDEs.
When a user runs CMake it performs a variety of checks similar to how autoconf worked historically. During the checks and the evaluation of the build description scripts CMake caches values into the CMakeCache. This is useful because it allows the build system to skip long-running checks during incremental development. CMake caching also has some drawbacks, but that will be discussed later.
Scripting Overview¶
CMake’s scripting language has a very simple grammar. Every language construct is a command that matches the pattern _name_(_args_). Commands come in three primary types: language-defined (commands implemented in C++ in CMake), defined functions, and defined macros. The CMake distribution also contains a suite of CMake modules that contain definitions for useful functionality.
The example below is the full CMake build for building a C++ “Hello World” program. The example uses only CMake language-defined functions.
cmake_minimum_required(VERSION 3.2)
project(HelloWorld)
add_executable(HelloWorld HelloWorld.cpp)
The CMake language provides control flow constructs in the form of foreach loops and if blocks. To make the example above more complicated you could add an if block to define “APPLE” when targeting Apple platforms:
cmake_minimum_required(VERSION 3.2)
project(HelloWorld)
add_executable(HelloWorld HelloWorld.cpp)
if(APPLE)
target_compile_definitions(HelloWorld PUBLIC APPLE)
endif()
Variables, Types, and Scope¶
Dereferencing¶
In CMake variables are “stringly” typed. All variables are represented as
strings throughout evaluation. Wrapping a variable in ${}
dereferences it
and results in a literal substitution of the name for the value. CMake refers to
this as “variable evaluation” in their documentation. Dereferences are performed
before the command being called receives the arguments. This means
dereferencing a list results in multiple separate arguments being passed to the
command.
Variable dereferences can be nested and be used to model complex data. For example:
set(var_name var1)
set(${var_name} foo) # same as "set(var1 foo)"
set(${${var_name}}_var bar) # same as "set(foo_var bar)"
Dereferencing an unset variable results in an empty expansion. It is a common pattern in CMake to conditionally set variables knowing that it will be used in code paths that the variable isn’t set. There are examples of this throughout the LLVM CMake build system.
An example of variable empty expansion is:
if(APPLE)
set(extra_sources Apple.cpp)
endif()
add_executable(HelloWorld HelloWorld.cpp ${extra_sources})
In this example the extra_sources
variable is only defined if you’re
targeting an Apple platform. For all other targets the extra_sources
will be
evaluated as empty before add_executable is given its arguments.
Lists¶
In CMake lists are semi-colon delimited strings, and it is strongly advised that you avoid using semi-colons in lists; it doesn’t go smoothly. A few examples of defining lists:
# Creates a list with members a, b, c, and d
set(my_list a b c d)
set(my_list "a;b;c;d")
# Creates a string "a b c d"
set(my_string "a b c d")
Lists of Lists¶
One of the more complicated patterns in CMake is lists of lists. Because a list cannot contain an element with a semi-colon to construct a list of lists you make a list of variable names that refer to other lists. For example:
set(list_of_lists a b c)
set(a 1 2 3)
set(b 4 5 6)
set(c 7 8 9)
With this layout you can iterate through the list of lists printing each value with the following code:
foreach(list_name IN LISTS list_of_lists)
foreach(value IN LISTS ${list_name})
message(${value})
endforeach()
endforeach()
You’ll notice that the inner foreach loop’s list is doubly dereferenced. This is
because the first dereference turns list_name
into the name of the sub-list
(a, b, or c in the example), then the second dereference is to get the value of
the list.
This pattern is used throughout CMake, the most common example is the compiler flags options, which CMake refers to using the following variable expansions: CMAKE_${LANGUAGE}_FLAGS and CMAKE_${LANGUAGE}_FLAGS_${CMAKE_BUILD_TYPE}.
Other Types¶
Variables that are cached or specified on the command line can have types associated with them. The variable’s type is used by CMake’s UI tool to display the right input field. A variable’s type generally doesn’t impact evaluation, however CMake does have special handling for some variables such as PATH. You can read more about the special handling in CMake’s set documentation.
Scope¶
CMake inherently has a directory-based scoping. Setting a variable in a CMakeLists file, will set the variable for that file, and all subdirectories. Variables set in a CMake module that is included in a CMakeLists file will be set in the scope they are included from, and all subdirectories.
When a variable that is already set is set again in a subdirectory it overrides the value in that scope and any deeper subdirectories.
The CMake set command provides two scope-related options. PARENT_SCOPE sets a variable into the parent scope, and not the current scope. The CACHE option sets the variable in the CMakeCache, which results in it being set in all scopes. The CACHE option will not set a variable that already exists in the CACHE unless the FORCE option is specified.
In addition to directory-based scope, CMake functions also have their own scope. This means variables set inside functions do not bleed into the parent scope. This is not true of macros, and it is for this reason LLVM prefers functions over macros whenever reasonable.
Note
Unlike C-based languages, CMake’s loop and control flow blocks do not have their own scopes.
Control Flow¶
CMake features the same basic control flow constructs you would expect in any scripting language, but there are a few quirks because, as with everything in CMake, control flow constructs are commands.
If, ElseIf, Else¶
Note
For the full documentation on the CMake if command go here. That resource is far more complete.
In general CMake if blocks work the way you’d expect:
if(<condition>)
message("do stuff")
elseif(<condition>)
message("do other stuff")
else()
message("do other other stuff")
endif()
The single most important thing to know about CMake’s if blocks coming from a C
background is that they do not have their own scope. Variables set inside
conditional blocks persist after the endif()
.
Loops¶
The most common form of the CMake foreach
block is:
foreach(var ...)
message("do stuff")
endforeach()
The variable argument portion of the foreach
block can contain dereferenced
lists, values to iterate, or a mix of both:
foreach(var foo bar baz)
message(${var})
endforeach()
# prints:
# foo
# bar
# baz
set(my_list 1 2 3)
foreach(var ${my_list})
message(${var})
endforeach()
# prints:
# 1
# 2
# 3
foreach(var ${my_list} out_of_bounds)
message(${var})
endforeach()
# prints:
# 1
# 2
# 3
# out_of_bounds
There is also a more modern CMake foreach syntax. The code below is equivalent to the code above:
foreach(var IN ITEMS foo bar baz)
message(${var})
endforeach()
# prints:
# foo
# bar
# baz
set(my_list 1 2 3)
foreach(var IN LISTS my_list)
message(${var})
endforeach()
# prints:
# 1
# 2
# 3
foreach(var IN LISTS my_list ITEMS out_of_bounds)
message(${var})
endforeach()
# prints:
# 1
# 2
# 3
# out_of_bounds
Similar to the conditional statements, these generally behave how you would expect, and they do not have their own scope.
CMake also supports while
loops, although they are not widely used in LLVM.
Modules, Functions and Macros¶
Modules¶
Modules are CMake’s vehicle for enabling code reuse. CMake modules are just CMake script files. They can contain code to execute on include as well as definitions for commands.
In CMake macros and functions are universally referred to as commands, and they are the primary method of defining code that can be called multiple times.
In LLVM we have several CMake modules that are included as part of our distribution for developers who don’t build our project from source. Those modules are the fundamental pieces needed to build LLVM-based projects with CMake. We also rely on modules as a way of organizing the build system’s functionality for maintainability and re-use within LLVM projects.
Argument Handling¶
When defining a CMake command handling arguments is very useful. The examples
in this section will all use the CMake function
block, but this all applies
to the macro
block as well.
CMake commands can have named arguments that are requried at every call site. In
addition, all commands will implicitly accept a variable number of extra
arguments (In C parlance, all commands are varargs functions). When a command is
invoked with extra arguments (beyond the named ones) CMake will store the full
list of arguments (both named and unnamed) in a list named ARGV
, and the
sublist of unnamed arguments in ARGN
. Below is a trivial example of
providing a wrapper function for CMake’s built in function add_dependencies
.
function(add_deps target)
add_dependencies(${target} ${ARGN})
endfunction()
This example defines a new macro named add_deps
which takes a required first
argument, and just calls another function passing through the first argument and
all trailing arguments.
CMake provides a module CMakeParseArguments
which provides an implementation
of advanced argument parsing. We use this all over LLVM, and it is recommended
for any function that has complex argument-based behaviors or optional
arguments. CMake’s official documentation for the module is in the
cmake-modules
manpage, and is also available at the
cmake-modules online documentation.
Note
As of CMake 3.5 the cmake_parse_arguments command has become a native command and the CMakeParseArguments module is empty and only left around for compatibility.
Functions Vs Macros¶
Functions and Macros look very similar in how they are used, but there is one fundamental difference between the two. Functions have their own scope, and macros don’t. This means variables set in macros will bleed out into the calling scope. That makes macros suitable for defining very small bits of functionality only.
The other difference between CMake functions and macros is how arguments are passed. Arguments to macros are not set as variables, instead dereferences to the parameters are resolved across the macro before executing it. This can result in some unexpected behavior if using unreferenced variables. For example:
macro(print_list my_list)
foreach(var IN LISTS my_list)
message("${var}")
endforeach()
endmacro()
set(my_list a b c d)
set(my_list_of_numbers 1 2 3 4)
print_list(my_list_of_numbers)
# prints:
# a
# b
# c
# d
Generally speaking this issue is uncommon because it requires using non-dereferenced variables with names that overlap in the parent scope, but it is important to be aware of because it can lead to subtle bugs.
LLVM Project Wrappers¶
LLVM projects provide lots of wrappers around critical CMake built-in commands. We use these wrappers to provide consistent behaviors across LLVM components and to reduce code duplication.
We generally (but not always) follow the convention that commands prefaced with
llvm_
are intended to be used only as building blocks for other commands.
Wrapper commands that are intended for direct use are generally named following
with the project in the middle of the command name (i.e. add_llvm_executable
is the wrapper for add_executable
). The LLVM add_*
wrapper functions are
all defined in AddLLVM.cmake
which is installed as part of the LLVM
distribution. It can be included and used by any LLVM sub-project that requires
LLVM.
Note
Not all LLVM projects require LLVM for all use cases. For example compiler-rt can be built without LLVM, and the compiler-rt sanitizer libraries are used with GCC.
 This document isn’t going to go into details about them because The CMake project has excellent documentation. To highlight a few useful functions see:
The full documentation for CMake commands is in the cmake-commands
manpage
and available on CMake’s website


53. Frame Details Window
.
54. The Purpose of Frame Details Window
This window is used to get detailed statistics about frames.
It provides information about a given frame ID across all frames with that ID. You can get such information as the number of frames, the number of data bytes that frame ID has, the average interval between frames with that ID, and the minimum and maximum interval.
Also listed are detailed statistics for each data byte in that frame. Each byte has listed which bits changed, the range of values found, and a histogram both graphically (at the righthand side of the window) and textually. The textual representation shows the number of times a specific value occurred.
The top right graph is a histogram of all the bits and the number of times each bit was set. This can be used to quickly visually see where data has changed.
The bottom right graph is of each individual byte as its value varies over time. All textual information can be saved to a text file for later analysis.


#include <GrRenderAmbience.h>
Public Member Functions | |
| GrRenderAmbience (GrStreamingIB *streamingIB, unsigned int maxIndexBatchSize) | |
| class GrRenderAmbience | |
| ~GrRenderAmbience () | |
| void | SetWireframeEnable (bool wireframe) |
| void | SetColorTextureEnable (bool enable) |
| void | RenderAmbience (GrRenderList &postRenderObjects, const GrRenderList &objects, const GrCamera &camera, const GrColor &ambientColor, unsigned int time, EGRQUALITY quality) |
| public methods |
Definition at line 26 of file GrRenderAmbience.h.
| GrRenderAmbience::GrRenderAmbience | ( | GrStreamingIB * | streamingIB, | |
| unsigned int | maxIndexBatchSize | |||
| ) |
class GrRenderAmbience
ctor & dtor
get the normalization texture cube.
get the default bump map.
get the stipple masks.
get the default white texture.
get the default black texture.
Definition at line 44 of file GrRenderAmbience.cpp.
| GrRenderAmbience::~GrRenderAmbience | ( | ) |
Definition at line 71 of file GrRenderAmbience.cpp.
| void GrRenderAmbience::RenderAmbience | ( | GrRenderList & | postRenderObjects, | |
| const GrRenderList & | objects, | |||
| const GrCamera & | camera, | |||
| const GrColor & | ambientColor, | |||
| unsigned int | time, | |||
| EGRQUALITY | quality | |||
| ) |
public methods
is there anything to do?
notify the ubertexture cache of tiles.
configure render states for rendering.
bind our system shaders and various system textures
get the view projection matrix.
calculate useful information.
sort objects by state.
if texturing isn't enabled, bind default textures.
render all of the objects.
get the current material span.
add all objects using this material to the post render list if necessary.
do we need to bind the stipple mask texture?
bind the stipple texture.
get the next stipple texture.
for each pass in the current material, render all objects in our span.
get the current pass for rendering and apply texture stages.
get the ambient shader.
bind the current shader.
apply texture stages and vertex params.
shade each object.
get the current renderable.
is the mesh pretransformed?
TODO: optimize this. calculate local space parameters.
apply local space parameters.
render the object.
Definition at line 83 of file GrRenderAmbience.cpp.
| void GrRenderAmbience::SetColorTextureEnable | ( | bool | enable | ) | [inline] |
Definition at line 33 of file GrRenderAmbience.h.
| void GrRenderAmbience::SetWireframeEnable | ( | bool | wireframe | ) | [inline] |
Definition at line 32 of file GrRenderAmbience.h.


Green Organic Dutchman shares fall after it reports $20.1M loss
by The Canadian Press, StaffMISSISSAUGA, Ont. - The Green Organic Dutchman Holdings Ltd. shares fell sharply in early trading following a $20.1 million third quarter loss for the cannabis company as the industry struggles to meet expectations.
Its stock fell about eight per cent to 76 cents soon after the open at the Toronto Stock Exchange, on top of a 9.8 per cent decline on Thursday before the results were released.
The Mississauga-based company says its loss increased from $11.3 million in the same quarter last year as costs rose from its expansion towards commercial production.
The results worked out to a loss of seven cents per share for the quarter ending Sept. 30, up from a loss of four cents in the same quarter last year.
The company says it invested $104 million in capital spending in the quarter, including the continued construction of two facilities in Ontario and Quebec.
It announced in October that it was significantly scaling back the timeline of its project in Valleyfield, Que., to reduce its cash needs.


S.A.F.E. on Campus
Sexual Assault Finally Ends
Home
Stay Safe
Share Your Story
Meet the Team
Feel free to share your
personal stories and advice.
Name:
Remain Anonymous
Comment:
Submit


Simple Cyphers
Making and Breaking
Here's the problem: We have a message we want to send, and we want only certain people to be able to read it. Sometimes we cannot guarantee that only the people we want will be the ones to see the message. Encryption is the act of changing a message so that people cannot read it unless they know how to decrpyt the message back again.
Encryption is usually spoken about in two parts: There's the cypher, which is the general method that you will use to encrypt and decrypt your message. There's also the key, which is usually a small but crucial piece of information, without which your opponents will struggle to decrypt your message. Think of it as a locked door: Everyone knows roughly how locks work (and you should assume everyone knows how your cypher works,) but people with the key find it far easier to get through the door.
Note that your opponents will find it hard, not impossible, to decrypt messages. They can keep on guessing which key will work until they eventually find the right one. Finding the key is known as breaking the encryption. Realistically one usually speaks of how long it will take someone to read your messages. If it takes someone over a hundred years to read your messages to your bank, then it's pretty likely you will have already closed that account by then and so those messages are considered "safe enough."
Letters and numbers
The roman alphabet comes in a specific order (A then B then C, etc.) so we can refer to letters either directly A, B, C ... or by their position in the list A = 1, B = 2, C = 3, ...
Here's a table of the letters and their associated number, so you don't have to work it out every time.
The Caesar Cypher
Supposedly this cypher was used by Julius Caeser to send orders to generals without spies reading them. It works by taking each letter in turn and shifting it a certain number of places through the alphabet. So if we wanted to shift the letter "B" by 5, we
- look up the value for "B", which is 2
- add 5 to get 7,
- then look up the letter for 7 which is "G".
Try it here: I take the letter , I shift it by places to the right and get the answer .
We want to send a message privately. For example, here's a message:
We want to shift each letter places to the right. This gives us:Caesar's general has just received the message
So what are they to do with it? Caesar, being organised, told the generals before leaving Rome that each letter was going to be shifted by , (this part is the key) so all the generals need to do is shift each letter back again.We want to shift each letter places to the left. This gives us:
Here are some things to think about:
- How can you tell if you have broken this cypher?
- How long would it take you to break this cypher?
- Why could it be a bad idea to include punctuation?
The Vigenère Cypher
The Caesar cypher can be broken in just twenty-six guesses, so if your opponent knows what sort of encryption you are using (you should always assume they do know this) then they can break it pretty quickly. There's a way of combining multiple Caesar cyphers, attributed to Blaise de Vigenère in the sixteenth century, that makes use of multiple Caesar cyphers in succession.
The Caesar Cypher shifted every single letter by the same number of places. What if we shifted the first letter by, say, 2, then the second by 5, then the next by 2, then 5, then 2, and so on? Instead of having to guess 1 thing from 26 options, your opponents now have to guess 1 thing from 26 x 26 options! Your allies, too, need to know both "2" and "5" (in that order) as the key. But wait! We can convert numbers to letters, and then it makes sense to put them next to each other in order. "2" then "5" is "B" then "E" as letters, so we could just tell our allies the word "BE".
The Vigenère Cypher works by taking a word, like " ", and using those letters over and over again as though they were keys for Caesar Cyphers.
So in each column we have: The letter we want to encrypt, the letter we treat as the key for a Caesar Cypher, and then the encrypted letter. Notice that changing one letter in the key affects only some of the encrypted text, but changing the length of the key changes the whole text (apart from the initial few letters.) We decode again using the same key, but doing the Caesar Cyphers backwards. Try putting in different keys here:
More questions:
- What happens when you just have a key word that is one letter long?
- How long would it take you to break this cypher knowing the key has four letters?
- How long would it take you to break this cypher when you don't know how long the key is?


UN Comtrade
Free access to detailed global
trade data. UN Comtrade is a
repository of official international
trade statistics and relevant
analytical tables. All data is
accessible through API.
United Nations International Trade Statistics Database, Department of Economic and Social Affairs/Statistics Division


1.0.0
Errors for AFilters.js - Advanced Filters Library.
Utilities for AFilters.js - Advanced Filters Library.
Throws Error indicates that argument is not a Function
Extends Error
(any)
Throws Error indicates that invalid approach passed
Extends Error
(any)
Throws Error indicates that no filters added
Extends Error
Throws Error indicates that no filters added
Extends Error
Throws Error indicates that invalid option passed
Extends Error
(any)
(any)
AFilters.js - Advanced Filters Library main file.
(Object
= {}
)
| Name | Description |
|---|---|
$0.filters any
(default [] )
|
|
$0.approach any
(default 'AND' )
|
|
$0.final any
|
(Object)
The desired options to set
(string?)
options.approach - Pre-defined approach
> const f = new Filter((arg1) => Boolean(arg1));
> f.try(1).finally((arg1, {returned}) => console.log(`Arg ${arg1} is ${returned[0]}`));
Arg 1 is true
> f.addFinal((arg1, {returned}) => console.log(`Arg ${arg1} = ${returned[0]}`));
> f.repeat(2);
Arg 2 = true
All allowed Approaches can be available from Filter class.
new Filter().setApproach(Filter.Approaches.OR)
Run filter with args and added the final function
(...any)
any
:
Set new options for current Filter (chaining)
(Object)
Object with allowed options
Filter
:
Set the final function and return this filter (chaining)
(Function)
The final function to start when filters will be passed.
Set current approach by method and return this filter (chaining) (from Approaches)
(String)
Filter
:
Return current approach name (from Approaches)
string
:
Update current approach to the desired allowed approach (from Approaches)
(any)
Enum of the Available Approaches
Type: string


This is a template for my custom directive. The controller for this directive is named "{{ dvm.name }}" and was initialized with "{{ initial }}"
The directive has it's own scope. Which can be optionally shared
| Shared | Private |
|---|---|
| {{ magic }} | {{ dvm.private }} |


--- title: budgetzero description: Track and optimize your sales team in real time --- Control your money. Control your data. Free, open-source, offline-first budgeting. Zero-based envelope budgeting done right -- with no strings attached. Start Budgeting Download for Desktop or Self Host
Free, open-source, offline-first budgeting. Zero-based envelope budgeting done right -- with no strings attached.
Want to stay up to date on new features & news?
Submit


Trumplandia: Portland's Independent Businesses and Gordon Sondland
Hey Portland, this one is going to burn a little. While the global perception of Portland is of a liberal weirdo wonderland, some of our city& »
Hey Portland, this one is going to burn a little. While the global perception of Portland is of a liberal weirdo wonderland, some of our city& »
I'm on the developer relations team at Mozilla. The "devrel" role has many parts, but generally means communicating to developers about web »
I've got a Firefox profile with 1691 tabs. I started trying to write down why, but gave up for now. It was becoming an »
This post is part of the Augmented City series. The first post is introduced A-Frame as a tool for creating 3D content for the web. The »
Hello! This guide is written for the Augmented City AR/VR lab in Singapore on July 15th 2017, but might be helpful for anyone looking to »


| knitr_options_pdf {rmarkdown} | R Documentation |
Define knitr options for an R Markdown output format that creates PDF output.
knitr_options_pdf(fig_width, fig_height, fig_crop, dev = "pdf")
fig_width |
Default width (in inches) for figures |
fig_height |
Default height (in inches) for figures |
fig_crop |
|
dev |
Graphics device to use for figure output (defaults to png) |
An list that can be passed as the knitr
argument of the
output_format
function.


Q. 18. What did God give Adam and Eve besides bodies?
A. He gave them souls that could never die.
Q. 19. Have you a soul as well as a body?
A. Yes; I have a soul that can never die.
Q. 20. How do you know that you have a soul?
A. Because the Bible tells me so.
Q. 21. In what condition did God make Adam and Eve?
A. He made them holy and happy.


Lab 4 for WEDB 335!
A todo title is required.
A todo description is required.
A todo status is required.
Enter a valid email.


Final Security Good Practices
|
|
| Mobile Platform |
Android App ; IoT System |
| Application domain type |
Smart Wearables |
| Authentication |
Yes |
| Authentication schemes |
Biometric-based authentication ; Channel-based authentication ; Factors-based authentication ; ID-based authentication |
| Has DB |
Yes |
| Type of database |
SQL (Relational Database) |
| Which DB |
MySQL |
| Type of information handled |
Personal Information ; Confidential Data ; Critical Data |
| Storage Location |
Both |
| User Registration |
Yes |
| Type of Registration |
The users will register themselves |
| Programming Languages |
Java |
| Input Forms |
Yes |
| Upload Files |
Yes |
| The system has logs |
Yes |
| The system has regular updates |
Yes |
| The system has third-party |
Yes |
| System Cloud Environments |
Hybrid Cloud |
| Hardware Specification |
No |
| HW Authentication |
Basic Authentication (user/pass) |
| HW Wireless Tech |
3G ; 4G/LTE ; 5G ; Bluetooth ; Wi-Fi ; GPS ; RFID ; ZigBee |
| Device or Data Center Physical Access |
Yes |
IoT Security Best Practices Guidelines
Internet of Things (IoT) devices fall into three main categories:
- Sensors, which gather data;
- Actuators, which effect actions;
- Gateways, which act as communication hubs and may also implement some
automation logic.
All these device types may stand alone or be embedded in a larger product. They may also be complemented by a web application or mobile device app and cloud based service.
IoT devices, services and software, and the communication channels that connect them, are at risk of attack by a variety of malicious parties.
Malicious intent commonly takes advantage of poor design, but even unintentional leakage of data due to ineffective security controls can also bring dire consequences to consumers and vendors. Thus it is vital that IoT devices and services have security designed in from the outset.
Classification of Data
- Define a data classification scheme and document it;
- Assess every item of data stored, processed, transmitted or received by a device and apply a data classification rating to it;
- Ensure the security design protects every data item and collections of items against unauthorised viewing, changing or deletion, to at least its classification rating or higher.
Physical Security
- Any interface used for administration or test purposes during development should be removed from a production device, disabled or made physically inaccessible;
- All test access points on production units must be disabled or locked, for example by blowing on-chip fuses to disable JTAG;
- If a production device must have an administration port, ensure it has effective access controls, e.g. strong credential management, restricted ports, secure protocols etc.;
- Make the device circuitry physically inaccessible to tampering, e.g. epoxy chips to circuit board, resin encapsulation, hiding data and address lines under these components etc;
- Provide secure protective casing and mounting options for deployment of devices in exposed locations;
- For high-security deployments, consider design measures such as active masking or shielding to protect against side-channel attacks.
Device Secure Boot
- Make sure the ROM-based secure boot function is always used. Use a multi-stage boot loader initiated by a minimal amount of read-only code;
- Use a hardware-based tamper-resistant capability (e.g. a microcontroller security subsystem, Secure Access Module (SAM) or Trusted Platform Module (TPM)) to store crucial data items and run the trusted authentication/cryptographic functions required for the boot process. Its limited secure storage capacity must hold the read-only first stage of the boot loader and all other data required to verify the authenticity of firmware;
- Check each stage of boot code is valid and trusted immediately before running that code. Validating code immediately before its use can reduce the risk of attacks;
- At each stage of the boot sequence, wherever possible, check that only the expected hardware is present and matches the stage's configuration parameters;
- Do not boot the next stage of device functionality until the previous stage has been successfully booted;
- Ensure failures at any stage of the boot sequence fail gracefully into a secure state, to ensure no unauthorised access is gained to underlying systems, code or data. Any code run must have been previously authenticated.
Secure Operating System
- Include in the operating system (OS) only those components (libraries, modules, packages etc.) that are required to support the functions of the device;
- Shipment should include the latest stable OS component versions available;
- Devices should be designed and shipped with the most secure configuration in place;
- Continue to update OS components to the latest stable versions throughout the lifetime of a deployed device;
- Disable all ports, protocols and services that are not used;
- Set permissions so users/applications cannot write to the root file system;
- If required, accounts for ordinary users/applications must have minimum access rights to perform the necessary functions. Separate administrator accounts (if required)will have greater rights of access. Do not run anything as root unless genuinely unavoidable;
- Ensure all files and directories are given the minimum access rights to perform the required functions;
- Consider implementing an encrypted file system.
Application Security
- Applications must be operated at the lowest privilege level possible, not as root. Applications must only have access to those resources they need;
- Applications should be isolated from each other. For example, use sandboxing techniques such as virtual machines, containerisation, Secure Computing Mode (seccomp), etc
- Ensure compliance with in-country data processing regulations;
- Ensure all errors are handled gracefully and any messages produced do not reveal any sensitive information;
- Never hard-code credentials into an application. Credentials must be stored separately in secure trusted storage and must be updateable in a way that ensures security is maintained;
- Remove all default user accounts and passwords;
- Use the most recent stable version of the operating system and libraries;
- Never deploy debug versions of code. The distribution should not include compilers, files containing developer comments, sample code, etc.;
- Consider the impact on the application/system if network connectivity is lost. Aim to maintain normal functionality and security wherever possible.
Credential Management
- A device should be uniquely identifiable by means of a factory-set tamper resistant hardware identifier if possible;
- Use good password management techniques, for example no blank or simple passwords allowed, never send passwords across a network (wired or wireless) in clear text, and employ a secure password reset process;
- Each password stored for authenticating credentials must use an industry standard hash function, along with a unique salt value that is not obvious (for example, not a username);
- Store credentials or encryption keys in a Secure Access Module (SAM), Trusted Platform Module (TPM), Hardware Security Module (HSM) or trusted key store if possible;
- Aim to use 2-factor authentication for accessing sensitive data if possible;
- Ensure a trusted & reliable time source is available where authentication methods require this, e.g. for digital certificates;
- A certificate used to identify a device must be unique and only used to identify that onedevice. Do not reuse the certificate across multiple devices;
- A "factory reset" function must fully remove all user data/credentials stored on a device.
Encryption
- When configuring a secure connection, if an encryption protocol offers a negotiable selection of algorithms, remove weaker options so they cannot be selected for use in a downgrade attack;
- Store encryption keys in a Secure Access Module (SAM), Trusted Platform Module (TPM), Hardware Security Module (HSM) or trusted key store if possible;
- Do not use insecure protocols, e.g. FTP, Telnet;
- It should be possible to securely replace encryption keys remotely;
- If implementing public/private key cryptography, use unique keys per device and avoid using global keys. A device's private key should be generated by that device or supplied by an associated secure credential solution, e.g. smart card. It should remain on that device and never be shared/visible to elsewhere.
Network Connections
- Activate only those network interfaces that are required (wired, wireless - including Bluetooth etc.);
- Run only those services on the network that are required;
- Open up only those network ports that are required;
- Run a correctly configured software firewall on the device if possible;
- Always use secure protocols, e.g. HTTPS, SFTP;
- Never exchange credentials in clear text or over weak solutions such as HTTP Basic Authentication;
- Authenticate every incoming connection to ensure it comes from a legitimate source.
- Authenticate the destination before sending sensitive data.
Logging
- Ensure all logged data comply with prevailing data protection regulations;
- Run the logging function in its own operating system process, separate from other functions;
- Store log files in their own partition, separate from other system files.
- Set log file maximum size and rotate logs;
- Where logging capacity is limited, just log start-up and shutdown parameters, login/access attempts and anything unexpected;
- Restrict access rights to log files to the minimum required to function;
- If logging to a central repository, send log data over a secure channel if the logs carry sensitive data and/or protection against tampering of logs must be assured;
- Implement log "levels" so that lightweight logging can be the standard approach, but with the option to run more detailed logging when required;
- Monitor and analyse logs regularly to extract valuable information and insight;
- Passwords and other secret information should not ever be displayed in logs.
(https://www.iotsecurityfoundation.org/wp-content/uploads/2019/03/Best-Practice-Guides-Release-1.2.1.pdf)[https://www.iotsecurityfoundation.org/wp-content/uploads/2019/03/Best-Practice-Guides-Release-1.2.1.pdf]
Security Best Practices Guidelines for Authentication
Security Best Practices for Authentication
Authentication is an important part of the security of any system. Here are best practices that should be followed to ensure a secure authentication process:
- Use strong passwords. Passwords should be at least 8 characters long and should include both upper and lowercase letters, numbers and special characters.
- Use multi-factor authentication whenever possible. This requires users to provide additional forms of authentication, such as a one-time code sent to a phone or email.
- Use a security question to protect accounts. This should be a question that is difficult for outsiders to answer but easy for the user to remember.
- Require users to change their password regularly. This helps reduce the risk of stolen credentials.
- Don’t allow the same password to be used again after expiration or change.
- Limit log-in attempts. If too many invalid attempts are made, lock the account.
- Implement a lockout policy. After a certain number of failed attempts, lock the account and require the user to reset the password.
- Monitor user log-ins and suspicious activity.
- Don’t store passwords in plain text. All passwords should be encrypted.
- Use security protocols such as TLS or SSL.
- Keep authentication systems up-to-date with the latest patches and security fixes.
- Ensure that all staff are properly trained on authentication best practices.
Security Best Practices Guidelines for Multifactor Authentication
Security Best Practices Guidelines for Multifactor Authentication
-
Implement Multi-Factor Authentication (MFA) where appropriate:
- Use MFA to protect critical systems, high-value assets, and sensitive data.
- Utilize a variety of authentication methods, such as biometrics, tokens, etc.
-
Use a password manager:
- Utilize strong, unique passwords for each of your accounts.
- Leverage an identity and access management system to securely store and manage user credentials.
-
Monitor user login attempts:
- Monitor user login attempts (e.g. IP addresses, time of day access, etc.).
- Set regular reviews and alerts to detect suspicious account activity.
-
Stay up-to-date on attack techniques:
- Utilize threat intelligence services to gain awareness about attack trends.
- Continuously monitor industry developments and stay aware of emerging threats.
-
Educate users:
- Regularly educate users on best practices and the importance of multi-factor authentication.
- Educate users on common attack techniques and how to recognize suspicious activity.
-
Establish a documented process for user onboarding and offboarding:
- Establish defined roles and detail user access requirements.
- Leverage automation and process documentation to ensure consistency in user provisioning.
-
Use strong credential standards:
- Use secure passphrases or passwords that are at least 12 characters.
- Utilize multi-factor authentication to reduce security risks associated with weak credentials and passwords.
-
Automate password rotation:
- Automate the password rotation process to ensure accounts remain secure.
- Require users to periodically update their passwords to detect suspicious activity.
Security Best Practices Guidelines for Authorization
Authorization: Security Best Practices Guidelines
Authorization refers to the process of determining what users or groups of users are able to access certain resources in a system. Ensuring the appropriate security of authorization processes is an important part of maintaining the privacy and security of systems and data.
The following are some best practices to help ensure the proper security of authorization processes:
- Implement multiple authentication factors to provide both authorization and identification.
- Regularly monitor and audit user access to data and systems and ensure that access is only granted to the necessary individuals.
- Follow the principle of least privilege when providing user access to systems and data - only provide users with the least level of access necessary to perform their tasks.
- Follow data segregation and separation of duties to reduce the potential risk of compromised authentication.
- Ensure authorization processes are enforced across all organizational devices and systems.
- Utilize an authorization system that allows for periodic audits and reviews, as well as the ability to track changes.
- Establish protocols and policies that clearly define grant and access management practices.
- Utilize a password management system in order to provide users with secure and easy access to authorization credentials.
- Ensure authorization processes are kept up-to-date with the latest security protocols.
- Monitor for unauthorized access attempts and investigate suspicious activities.
- Provide users and administrators with consistent and continuous authorization training.
Security Best Practices Guidelines for Cryptographic Storage
Security Best Practices for Cryptographic Storage
Overview
Cryptographic Storage is the practice of maintaining sensitive data in an encrypted form. It helps to protect the confidentiality of your data even if it is stolen.
Security Practices
-
Identify confidential data to be protected: Identify the data that needs to be stored in encrypted form. This includes data such as user credentials, Personally Identifiable Information (PII), and proprietary information.
-
Implement strong cryptographic protocols: Use strong cryptographic protocols to encrypt the data. The cryptographic keys should never be shared or stored in plaintext.
-
Store the cryptographic keys securely: Use a secure mechanism such as hardware security modules (HSMs) to store the cryptographic keys.
-
Protect the cryptographic keys: Use access controls, such as authentication tokens, to protect the cryptographic keys. Do not allow unauthorized access to the keys.
-
Review security regularly: Perform periodic audits to check for any unauthorized access to the cryptographic keys.
-
Train staff on cryptographic storage: Ensure that your staff is trained on secure cryptographic storage practices.
Conclusion
By following the security best practices outlined above, you can ensure the safety of your data and your organization’s security.
Security Best Practices Guidelines for Database Security
Database Security Best Practices
1. Establish Separation of Duties
To help reduce the potential for fraud or unauthorized access, establish a separation of duties between those responsible for administering the database, those responsible for defining security policies, and those able to access the data.
2. Encrypt Data in Transit and at Rest
Where possible, use encryption techniques for data stored in the database and for data while it is in transit. This helps protect the data from malicious activity.
3. Restrict Database Access
Ensure that only authorized personnel have access to the database. Implement security measures such as user authentication, user profiles, role-based access control, two-factor authentication, etc.
4. Regularly Monitor Database Activity
Regularly monitor database activity and user access. Monitor authentication activities, login attempts, data modification requests, etc. Review logs regularly and ensure that access requests are authorized.
5. Update Databases Regularly
Databases can quickly become outdated and insecure. Make sure to regularly patch, update, and upgrade the database and applications running on it.
6. Regularly Test Database Security
Regularly test the security of the database to identify potential vulnerabilities. Also, test the strength of passwords and other security controls.
7. Implement An Active Database Backup Strategy
To minimize disruption in the event of a data breach or other security incident, maintain an active and testable database backup strategy.
8. Use Intrusion-Prevention Systems
Implement intrusion-prevention systems to monitor and protect the database from malicious activity.
Security Best Practices Guidelines for Denial of Service
Denial of Service (DoS)
A Denial-of-Service (DoS) attack is a malicious attempt to make a system unavailable, by consuming all of its resources so that legitimate requests can’t be served. The main goals of DoS attacks are to render systems unusable or significantly slow them down.
Best Practices
-
Secure Your Firewall and Perimeter Devices: Ensure that your firewall rules and configurations are updated and actively managed. Monitor and audit these components regularly for any changes or weaknesses that could be exploited.
-
Implement an Intrusion Detection and/or Prevention System (IDS/IPS): Detect and respond to malicious traffic, as early as possible. This can be done with an Intrusion Detection System (IDS) and/or an Intrusion Prevention System (IPS).
-
Monitor Network Activity and Logs: Track the source and duration of all incoming and outgoing traffic. Create rules that will alert you immediately when you detect suspicious activity. This will allow you to take action quickly and prevent the attack from escalating.
-
Establish Network Behavior Baselines: Establish a baseline for normal network traffic patterns and be prepared to identify any sudden spikes or abnormal activity.
-
Reduce Network Flows and Data: Take steps to reduce the amount of data flowing across your network. This can be done by limiting what services are accessible, or by setting up traffic filtering and prioritization rules.
-
Deploy Resources Appropriately: Make sure that load balancers, firewalls, and other networking devices are deployed in such a way that is capable of handling large amounts of traffic.
-
Periodically Sandbox: Periodically subject parts of the network to simulated DoS attacks. Use the results to identify weak spots and areas of improvement. This can be done using packet analyzers or DoS vulnerability assessment tools.
-
Be Prepared to Respond: Create a plan for responding to a DoS attack, anticipate different attack scenarios, and know how to identify any potential indicators of an attack in progress.
-
Educate Your Staff: Make sure that your staff is aware of the risks associated with DoS attacks and how to recognize suspicious activity. Train them periodically to ensure they are up-to-date on the
Security Best Practices Guidelines for File Upload
File Upload Security Best Practices
It is essential to establish effective security guidelines for the file upload process. The following are best practices that can help ensure privacy and security of systems and data:
-
Limiting Accessibility: Access to file uploads should be restricted, and user credentials should be verified each time an upload is attempted.
-
Requiring Authentication: Establish strong authentication methods such as two-factor authentication for any user attempting to upload files.
-
Monitoring Uploads: Monitor the uploads occurring on an ongoing basis for any malicious activity.
-
Backups: Establish a backup policy that addresses the time frequency of file uploads and the recovery process in the event of a security incident or disaster.
-
File Size Limitations: Place limits on the size of files that can be uploaded to help prevent malicious file uploads.
-
Data Validation: Establish data validation processes such as virus scanning to help ensure that only clean files are being uploaded into the system.
-
Encryption: Encrypt the data being uploaded to help ensure its privacy and security.
-
Auditing: Establish an audit policy to review the upload process and ensure that it is operating securely.
-
Logging: Log any file uploads to track and monitor activity.
-
Patching: Update the system with the latest security patches to ensure the latest protections are in place.
Security Best Practices Guidelines for Injection Prevention
Injection Prevention Best Practices
Injection vulnerabilities occur when user input is unexpectedly executed as code. Injection attacks can come in many forms, including SQLi, OS, and LDAP injections, and can cause substantial data loss and server damage. It is important to take precautions to prevent injection attacks from occurring.
General Best Practices
- Validate user input using whitelisting, type conversion, or other techniques
- Enforce input length and format constraints
- Implement output encoding for dynamic data
- Reduce attack surface area, minimizing the amount of code accessible to malicious users
- Sanitize and filter user input
- Check input strings for any malicious code
- Escaping special characters
- Use prepared statements, parameterized queries, and stored procedures for database interaction
- Audit and log all input and output operations
- Use API Gateway to control access to APIs
Web Security Best Practices
- Disable the use of backslash and commas in web applications
- Filter out SQL injection attempts from user input
- Filter out "naughty strings" (e.g. "DROP TABLE")
- Limit the number of characters in forms
- Sanitize regular expression data
- Use HTTPs for all network traffic
- Permit the use of only known file types
- Disallow the execution of arbitrary command line parameters
- Validate URL requests
- Use CAPTCHA for authentication
Following these best practices can help prevent injection attacks and ensure the safety of your system.
References:
- https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet
- https://www.veracode.com/security/injection-prevention
- https://www.netsparker.com/blog/web-security/prevent-sql-injection-attacks/
- https://www.zeropointsecurity.com/injection-attacks
Security Best Practices Guidelines for Injection Prevention in Java
Injection Prevention in Java
Best Practices
-
Input Validation: Validate user input to ensure that it adheres to acceptable format, length, type, and value before passing it to the application.
-
Whitelisting: Use whitelisting for accepting input data instead of blacklisting - that is, allow valid values and reject anything else.
-
Parameterised Queries: Use parameterised queries (aka prepared statements) when working with user input. This uses parameter binding instead of concatenation to construct queries, which makes it resistant to SQL injection attacks.
-
Stored Procedures: Use stored procedures with input validation instead of dynamic queries.
-
Object Relational Mapping (ORM): Use an ORM framework for accessing a database that provides database query parameterization and avoids the developers from writing dynamic SQL queries.
-
Use an Escape Mechanism: Use an escape function for escaping any potentially dangerous characters when user input is passed to a backend system.
-
Escaping Wildcard Characters: Escape all wildcard characters in user-supplied data to prevent wildcards expanding into a larger list of values when used in comparison operations.
-
Disable Object Relational Mapping (ORM) Metacommands: Disable ORM meta-commands (like Direct SQL) for preventing an application passing user input directly to a database without validation.
-
Enforce Timeouts and Request Limits: Enforce request timeouts and limit the number of requests an application allows from a particular user to limit the risk of attacks.
-
Regular Security Scanning: Perform regular security scanning of your application and use automated tools to check for anonymous access points, missing patches, and malicious code.
Security Best Practices Guidelines for Logging
Security Best Practices for Logging
Introduction
Logging is a critical component of operational security, which can be used to detect potential security incidents, verify compliance with internal and external regulatory requirements, and provide an audit trail for later forensic activities. Proper logging configurations and practice can help you protect the confidentiality, integrity, and availability of your system, as well as reduce the chances of data privacy breaches.
This guide provides an overview of some of the best practices for configuring, maintaining, and viewing logs.
Logging Practices
-
Establish a logging policy: Decide which logs need to be saved and how long the logs need to be retained, and share the policy with stakeholders.
-
Set up log aggregation and storage: Ensure that access and storage controls are configured on log files to protect the log data from manipulation or unauthorized access.
-
Choose appropriate log retention periods and awareness programs: Decide how long the logs should be retained before disposal.
-
Utilize log monitoring and analysis tool: Use a tool to automate the collection, analysis, and alerting on log data.
-
Configure the system to generate detailed logs: Detail the events required to capture in the logs including, but not limited to, user authentication, attempted logins, system startup/shutdown, system modifications, etc.
-
Encrypt data in transit and at rest: Ensure data is encrypted both in transit and at rest to protect sensitive data from unauthorized access.
-
Test logging regularly: Test the logging system regularly to ensure that all relevant data is being logged as desired.
-
Ensure only authorized users can view the logs: Apply role-based access control and passwords to prevent unauthorized access to log data.
-
Educate users on logging: Inform users about logging best practices and policies to avoid inadvertent violations.
Security Best Practices Guidelines for Logging Vocabulary
Logging Vocabulary Security Best Practices
-
Be Aware of Log-Levels: Understand the context of the information your application collects and what purpose it serves. For example, too much logging could impact performance and increase storage and processing overhead.
-
Limit Access to Logs: Make sure to limit access to log information to individuals and groups that really need it. Logging should never be exposed to the public.
-
Create Secure Log Storage: Choose a secure storage system for logs to minimize chances of tampering or unauthoirzed access.
-
Keep Track of Log "Events": Document and maintain a record of changes and additions to the log information.
-
Securely Delete Log Information: Log information should be securely deleted once it has served its purpose.
-
Configure and Enable Security Logging: Set up and enable logging for any security events, like failed authentication attempts, etc.
-
Audit Logging Systems: Periodically audit log systems to ensure that they are properly configured and functioning correctly.
-
Log File Integrity Monitoring: Monitor log files for integrity and ensure that they are not modified, overwritten, or deleted.
-
Follow Directive Rules: If your organization uses directives such as the European Union's GDPR, HIPAA, and Sarbanes-Oxley Act, make sure your logging practices comply with these regulations.
Security Best Practices Guidelines for Password Storage
Password Storage Best Practices Guidelines
-
Make your passwords long: Use a minimum of 8-10 characters; longer passwords are more secure.
-
Make your passwords complex: Include a mix of uppercase and lowercase letters, numbers, and special characters.
-
Avoid using personal and easily guessed details: Do not use your name, birthdate, address, or any other personally identifiable information in your password.
-
Do not use the same password for multiple accounts: It is more secure to use unique passwords for each account.
-
Keep your passwords safe: Store them in a secure password manager or use two-factor authentication when available. If you need to write down your passwords, keep them in a secure, locked place.
-
Change passwords regularly: Change your passwords at least every 3 months.
-
Be careful of suspicious links or email attachments: Never click on links or open attachments in emails from unknown or untrusted sources.
-
Be alert when logging in: Always check to make sure you are on a secure, legitimate website.
Security Best Practices Guidelines for SSRF Prevention
Security Best Practices Guidelines for SSRF Prevention
Server-Side Request Forgery (SSRF) is an attack that forces a server to perform requests on behalf of an attacker. It can be used to compromise data, bypass authentication, and gain access to internal systems.
The following security best practices can help prevent SSRF and protect against related attacks:
- Develop and deploy applications securely and ensure that any input from an untrusted source is sanitized and validated.
- Block access to all unnecessary services, especially those that can be used to send requests to other systems. This includes the likes of external APIs, databases, and filesystems.
- Set up an internal firewall to prevent external requests from entering the network.
- Implement strong authentication and access control restrictions to verify that only authorized users can access critical resources.
- Monitor and log all requests to internal and/or external services.
- Patch and maintain all servers, web applications, and operating systems regularly to keep them up to date.
- Educate and train all staff to be aware of the risks associated with SSRF attacks.
- Make sure third-party APIs and services are configured securely and have adequate security measures in place.
Security Best Practices Guidelines for Session Management
Session Management Best Practices
Session Management is an important part of securing web applications. Implementing good session management practices helps protect user data, prevent unauthorized access, and offers a more secure user experience.
Below are some best practices to help to ensure that you are properly managing user sessions and protecting user data:
Use Secure Cookie Policies when Storing Session Data
- Use secure HTTPS protocol when sending session data.
- Specify short expiration times on session cookies.
- Use "secure" and "httponly" attributes to further enhance cookie protection and disable cookie access from JavaScript code.
- Renew the session ID when sensitive data is updated.
Set Appropriate Access Controls
- Restrict access to authenticated users only.
- Enforce strong passwords and multi-factor authentication when possible.
- Limit access to resources to a specific IP address or range of addresses.
Monitor User Activity
- Monitor session data for signs of suspicious activities.
- Log failed login attempts.
- Implement an audit logging system to track user activities over time.
Implement Timeouts
- Use server side session timeouts to ensure that a user session is terminated when a set period of time has expired.
- Implement shorter timeouts for important transactions like online banking transactions.
Take Advantage of Automated Tools
- Use automated tools to help identify and track session data.
- Use automated tools to update application code and ensure that security issues are proactively addressed.
Following these best practices will help ensure that user data is secure and protected, and that web applications are operating in a safe and secure manner.
Security Best Practices Guidelines for Transport Layer Protection
Transport Layer Protection: Security Best Practices
It is important to ensure that your transport layer is secure to protect the confidentiality, integrity, and availability of your data. The following best practices should be followed when using transport layer protection:
Encryption
- Use TLS/SSL whenever possible for secure transit of data between clients and servers.
- Use strong encryption algorithms such as AES-256 and RSA-2048 to protect data.
- Use Elliptic-curve Cryptography (ECC) for its smaller key size and higher encryption strength.
Certificate Management
- Use only valid and trusted SSL certificates.
- Regularly check for revoked and expired certificates and take necessary steps to update them.
- Make sure all certificates used by the organization are up to date and properly configured.
Firewall & Network Security
- Make sure to enable firewall rules to allow only secure protocols like HTTPS/TLS.
- Use Intrusion Detection and Prevention Systems to prevent malicious packets from entering the network.
- Utilize monitoring and logging tools to detect and respond to suspicious or malicious activity on the network.
Authentication & Authorization
- Enable two-factor authentication when available, and use a secure password policy.
- Implement Role-Based Access Control (RBAC) to separate users and enforce access control.
- Use strong authentication methods such as digital certificates or biometrics.
Physical Security
- Implement appropriate physical security measures such as access control and CCTV surveillance.
- Monitor all external device connections such as USB drives.
- Ensure the secure storage of data center devices.
Security Best Practices Guidelines for Input Validation
Input Validation Security Best Practices
- Whitelisting: Use whitelisting to ensure only known reliable data enters the system.
- Data Minimization: When possible, minimize the amount of user supplied input data.
- Data Size Limitation: Restrict input data to a reasonable length.
- Data Type Limitation: Restrict input data to expected types and formats.
- Input Data Sanitization:Sanitize input data to strip out malicious content (e.g. tags, scripts).
- Input Data Encoding:Encode input data (e.g. HTML encoding) to prevent attackers from exploiting a known vulnerability.
- Verify Server Side: Perform checks and validation on the server side for all user supplied data.
- Data Format Validation: Validate any input data is in the required format.
- Reduce False Positives: Try to reduce any false positives that impede users from submitting their input data (e.g. CAPTCHAs).
- Logging and Monitoring: Monitor suspicious or malicious activity (e.g. failed logins attempts) around user input.
Security Best Practices Guidelines for User Privacy Protection
User Privacy Protection Best Practices
- Ensure explicit user consent for the collection and use of personal data.
- Collect and process only the necessary personal data to fulfil your organizations purpose.
- Securely store all collected personal data.
- Implement data access controls so that only those that need it have access to personal data.
- Ensure your data processing activities are documented.
- Only share personal data with third parties if necessary and if the third party has the right procedures and controls in place to protect the data.
- Give users the right to access, update, and delete their personal data.
- Notify users of any data breaches promptly and as required by law.
- Regularly reassess and revise your user privacy protection standards.
- Educate all personnel who have access to personal data on user privacy protection best practices.
Security Best Practices Guidelines for Cryptography
Security Best Practices for Cryptography
Cryptography is one of the most important tools when it comes to securing sensitive information. The following best practices should be implemented when using cryptography:
Key Management
- Generate strong cryptographic keys and store them securely.
- Back up cryptographic keys regularly in multiple secure locations.
- Properly revoke cryptographic keys that will no longer be used.
- Implement access control measures for cryptographic keys to prevent unauthorized access.
- Limit the number of administrators that have access to cryptographic keys.
Use of Cryptographic Algorithms
- Use only well-tested cryptographic algorithms and implementations.
- Regularly assess and update cryptographic algorithms if they become outdated or vulnerable.
- Use strong cryptographic algorithms such as AES and RSA.
- Utilize separate cryptographic implementations for different systems for better security.
Encryption
- Encrypt data at rest, in transit, and in memory.
- Never store unencrypted data or passwords.
- Ensure secure transmission of data over the network and across systems.
- Use separate encryption keys for different systems for better security.
Security Monitoring
- Implement proper security monitoring of cryptographic systems.
- Regularly audit cryptographic systems to ensure that they are secure and compliant.
- Monitor for unauthorized access to cryptographic keys and systems.
- Implement proper incident response measures for security breaches.
Security Best Practices Guidelines for Secure Application Update
Secure Update of Cloud-based Mobile Application
Best Practices Guidelines
This document details the best security practices for performing a secure update of a cloud-based mobile application.
1. Prepare a Secure Infrastructure
- Leverage a secure cloud infrastructure designed to ensure the security of the mobile application.
- Use a secure cloud environment such as a virtual private cloud (VPC) with dedicated firewalls and access control mechanisms.
- Ensure that the VPC is fully isolated from any other public services to minimize the risk of unauthorized access.
- Ensure that all security settings related to the VPC, such as ports, protocols, and authentication mechanisms, are properly configured to prevent potential threats and attacks.
2. Encrypt Sensitive User Data
- Ensure that sensitive user data is encrypted both at rest and in transit, using end-to-end encryption to protect against data leakage and malicious actors.
- Use strong cryptographic algorithms and regularly update them in order to remain up-to-date with the latest industry standards.
3. Use Multi-Factor Authentication
- Make sure that multi-factor authentication (MFA) is implemented for all users to provide an extra layer of security.
- Utilize different means for authentication, such as physical tokens, biometrics, one-time passwords, or mobile applications.
4. Implement Proper Access Controls
- Ensure that users and administrators are granted access to only those resources that are absolutely necessary.
- Implement least privilege principles to reduce the risk of unauthorized access of sensitive user data.
- Ensure that sensitive information is stored on secure servers with up-to-date access controls.
5. Ensure Regular Vulnerability Scanning
- Perform regular security scans in order to identify potential vulnerabilities before they can be exploited.
- Utilize web application scanning tools to identify and address any security issues in the code.
- Make sure that all servers are regularly updated with the latest security patches and fixes.
6. Monitor Logs and Monitor Network Activity
- Monitor all system logs and network activities in order to detect any suspicious or malicious activities.
- Utilize automated intrusion detection systems to detect any malicious attempts to break into the system.
7. Develop Secure Application Code
*
Security Best Practices Guidelines for Secure Third-party Application
Security Best Practices Guidelines for Secure Third-party Cloud-Based Mobile Applications
The following best practices are designed to ensure secure use of Cloud-Based Mobile Applications.
Proper User Authentication
-
Authentication should be based on strong credentials such as two-factor authentication whenever possible.
-
Application passwords should be strong and updated regularly. Make sure to store them securely.
-
User accounts should be locked out after multiple failed attempts to discourage brute force attacks.
Secure Communications
-
All communications should be encrypted and authenticated using industry-standard encryption protocols such as HTTPS and SSL/TLS.
-
Mobile Applications should only communicate with backend services over a secure data channel or VPN
Secure Data Storage
-
All sensitive data should be stored in an encrypted format.
-
Data should be stored on secure servers that are regularly patched with the latest security updates.
-
Access to sensitive data should be limited only to authenticated users.
Secure Data Transmission
Code Review
-
All code should be reviewed by a qualified security professional prior to deployment.
-
All external libraries and frameworks should be regularly updated to ensure that security vulnerabilities are patched.
Application Level Threat Protection
-
Mobile applications should be tested for security vulnerabilities and common attack vectors.
-
Mobile applications should include rate limiting, then monitor and block suspicious requests and activities.
Regular Updating
By following these best practices, organizations can ensure the secure use of third-party cloud-based mobile applications.


As you work in a field for long time, you develop a sense of what is doable and what is not. You try to work on the problems which are doable, and avoid working on the problems which are undoable. The categories are not black and white, and interesting problems are those which are hard but doable.
As I waded through my undergraduate and graudate courses in Computer Science, I formed an opinion about various fields. Some fields tackled doable problems while some others tackled undoables problems. The latter ones were to be avoided. There were other fields which tackled non problems. One could study them for fun.
Artificial Intellience was the flashiest of the fields, but it over promised and under delivered. I always thought Machine Learning is more sober name for the field, if at all it wanted itself to be separated from Algorithms. Deep Blue defeating Garry Kasparov was thought to be a high point in AI, but if you scratch the surface there was nothing that justified the name "Artifical Intelligence". Lot of opening theory is fed into the computer, end games can be looked up, and there is lot of hand tuning. Other things that we learnt in AI courses were VC dimension, regression trees, naive bayesian classifier, SVM and ANN. Recognizing handwritten digits was where the AI gave up, though I am sure there would be research papers that showed much more.
Then, starting 2012, AI started solving problems I had hitherto considered unsolvable. If, in 2010, you asked me write a program that could detect cats from dogs, I would have give up immediately. (Ok, not immediately perhaps!). But the deep learning area of AI provided with practical ways to solve problems that were till now untractable. [It is another matter that the techniques were discovered decades earlier, and those techniques became applicable only lately with the advent of large training data and compute capacity.]
This forced me to revise my perception of AI. The core learning was that the image classification function (and other similar functions) was learnable in a way that generalized well to images beyond the training examples.
So, which other fields are tackling undoable problems, or non problems? Here is a list. I would be great if a few of these items make it out of the list in my lifetime.
Quantum Computing has been perenially promising that once Quantum Computers are developed, they will be a million times faster than the existing computers. During the past 30 years that the Quantum Computing has been promising us a million times faster computers, traditional computers themselves have become a million times faster. Meanwhile, Quantum Computers keep celebrating Shor's algorithm and are happy to report that quantum computers have factorized 15 as 5 * 3 (2001), and that they have factorized 143 as 13 * 11 (2011).
Will Quantum Computing ever be widely available?
With multi core, super scalar processors available, won't it be great if there were a system that can convert your program, written with single stream of exeuction in mind, and parallelize it to run across cores?
Turns out that this is a problem which is hard, but not for the lack of trying. See for examples, this, or this.
In the absence of automatic parallelization, there have been two approaches to execute programs in parallel (a) Programmer writes his programs in a "parallel augmentation" of his favorite language. Most popular augmentation available is Message Passing Interface. Thus, the programmer is responsible to define the parallelism in his algorithm. (b) Programmer writes his program in a framework like Hadoop MapReduce. If he does so, he can write parallel algorithms for a large class of problems very easily, but not all problems (e.g. graph algorithms) lend themselves to map reduce.
So, while practically we have made progress in running our programs across compute threads, the holy grail of automatic program parallelization has eluded us.
At the base of Maths are axioms. Any theorem can be derived from those axioms using the rules of derivation. For exmaple, at the base of Euclidean Geometry are five axioms, and the basis of number theory are Peano Axioms.
So, can we write programs to automate theorem proving? Turns out that we do not yet know of ways that enable a computer program to wade through theorems, applying logic to go from one theorem to another, and arrive at a given theorem. What is more, even writing an automated proof checker is hard, though is used in some domains like integrated circuit design.
Genetic algorithms look plausible to begin with: just as in nature where offsprings combine genes from their parents, and have some mutations of their own, let us try to find the maxima/minima for a function by starting with a few random points, and then creating offsprings repeatedly. Just as in nature, we kill the unfit data points that we generate, thus operting with some fixed size population from generation to generation.
The problem is: nature is not particularly efficient at generating optimal species. Infact, nature is not even required to generate species that fit the environment: species go extinct all the time.
Thus, drawing inspiration from nature in this case is a bad idea. That however is not the opinion shared by conferences like this.
Note that drawing inspiration from nature is not always a bad idea: animals are very good at vision, and thus drawing inspiration from them to develop algorithms for computer vision is a good idea.


public class PerformanceScheduler extends java.lang.Thread implements Scheduler
Scheduler
providing means to send and process
messages between server and emulator. Uses temporary connection to server provided by
ServerController
.Scheduler
java.lang.Thread.State, java.lang.Thread.UncaughtExceptionHandler
Scheduler.Type
| Modifier and Type | Field and Description |
|---|---|
private AdapterController |
adapterController
adapter controller, that uses this scheduler instance
|
private boolean |
continueProcessing
processing indicator
|
private static org.apache.logging.log4j.Logger |
logger
Log4j2 logger field
|
private ResponseTracker |
responseTracker
response tracker instance
|
private static int |
SLEEP_INTERVAL
default sleep interval when internet connection is disabled
|
private boolean |
terminate
termination indicator
|
static Scheduler.Type |
TYPE
default scheduler type
|
| Constructor and Description |
|---|
PerformanceScheduler(AdapterController adapterController)
Creates instance of scheduler, that uses temporary connection to server.
|
| Modifier and Type | Method and Description |
|---|---|
void |
clearResponseTracker()
Clears saved responses
|
ResponseTracker |
getResponseTracker()
Gets assigned response tracker class.
|
Scheduler.Type |
getType()
Gets scheduler's type
|
boolean |
isContinueProcessing()
Indicates, whether scheduler is currently processing messages.
|
void |
processTracking(OutMessage message)
If response tracking is enabled, saves response time to adapter's log
message.
|
void |
run()
Method called after scheduler's thread is started.
|
void |
setResponseTracker(ResponseTracker responseTracker)
Sets response tracker for scheduler
|
void |
startProcessing()
Sets process indicator to start and notifies thread if it is waiting
|
void |
stopProcessing()
Sets process indicator to stop.
|
void |
terminateScheduler(boolean clearResponses)
Clears all saved responses in assigned
ResponseTracker and terminates
scheduler's thread. |
activeCount, checkAccess, clone, countStackFrames, currentThread, destroy, dumpStack, enumerate, getAllStackTraces, getContextClassLoader, getDefaultUncaughtExceptionHandler, getId, getName, getPriority, getStackTrace, getState, getThreadGroup, getUncaughtExceptionHandler, holdsLock, interrupt, interrupted, isAlive, isDaemon, isInterrupted, join, join, join, resume, setContextClassLoader, setDaemon, setDefaultUncaughtExceptionHandler, setName, setPriority, setUncaughtExceptionHandler, sleep, sleep, start, stop, stop, suspend, toString, yield
private static final int SLEEP_INTERVAL
private static final org.apache.logging.log4j.Logger logger
public static final Scheduler.Type TYPE
private boolean terminate
private boolean continueProcessing
private ResponseTracker responseTracker
private AdapterController adapterController
public PerformanceScheduler(AdapterController adapterController)
adapterController
- adapter controller, that will schedulerpublic void run()
Method called after scheduler's thread is started. Providing logic to send and process messages between server and emulator.
Scheduler processes messages saved in adapterController
.
If register message is to be sent, uses stable connection provided by
ServerReceiver
. If this message is successfully
sent, initiates listening on stable connection.
If common sensor message is to be sent, uses temporary connection provided by
ServerController
.
public void clearResponseTracker()
clearResponseTracker
in interface Scheduler
public void processTracking(OutMessage message)
processTracking
in interface Scheduler
message
- message to server containing adapter's log messagepublic void startProcessing()
startProcessing
in interface Scheduler
public void stopProcessing()
stopProcessing
in interface Scheduler
public void terminateScheduler(boolean clearResponses)
ResponseTracker
and terminates
scheduler's thread.terminateScheduler
in interface Scheduler
clearResponses
- true
if responses should be cleared, false
otherwisepublic ResponseTracker getResponseTracker()
getResponseTracker
in interface Scheduler
public void setResponseTracker(ResponseTracker responseTracker)
setResponseTracker
in interface Scheduler
responseTracker
- response trackerpublic boolean isContinueProcessing()
isContinueProcessing
in interface Scheduler
true
if processing, false
otherwisepublic Scheduler.Type getType()


Building on Mac OS¶
- Maintainer
Cameron Eagans<EMAIL_ADDRESS>This part of the documentation is written by Cameron Eagans, a co-maintainer of Universal-ctags and the maintainer of the OSX packaging of this project.
Build Prerequisites¶
Building ctags on OSX should be no different than building on GNU/Linux. The same toolchains are used, and the Mac OS packaging scripts use autotools and make (as you’d expect).
You may need to install the xcode command line tools. You can install the entire xcode distribution from the App Store,
or for a lighter install, you can simply run xcode-select --install
to only install the compilers and such. See
https://stackoverflow.com/a/9329325 for more information. Once your build toolchain is installed, proceed to the next
section.
At this point, if you’d like to build from an IDE, you’ll have to figure it out. Building ctags is a pretty straightforward process that matches many other projects and most decent IDEs should be able to handle it.
Building Manually (i.e. for development)¶
You can simply run the build instructions in README.md.
Building with Homebrew¶
Homebrew (https://brew.sh/) is the preferred method for installing Universal-ctags for end users. Currently, the process for installing with Homebrew looks like this:
brew tap universal-ctags/universal-ctags
brew install --HEAD universal-ctags
Eventually, we hope to move the Universal-ctags formula to the main Homebrew repository, but since we don’t have any tagged releases at this point, it’s a head-only formula and wouldn’t be accepted. When we have a tagged release, we’ll submit a PR to Homebrew.
If you’d like to help with the Homebrew formula, you can find the repository here: https://github.com/universal-ctags/homebrew-universal-ctags
Differences between OSX and GNU/Linux¶
There other things where building ctags on OSX differs from building on GNU/Linux.
Filenames on HFS+ (the Mac OS filesystem) are case-preserving, but not case-sensitive in 99% of configurations. If a user manually formats their disk with a case sensitive version of HFS+, then the filesystem will behave like normal GNU/Linux systems. Depending on users doing this is not a good thing.
Contributing¶
This documentation is very much a work in progress. If you’d like to contribute, submit a PR and mention @cweagans for review.


Bootstrap:docker
From:centos:latest
%labels
MAINTAINER Sven Fillinger
VERSION 1.0
EMAIL<EMAIL_ADDRESS>%runscript
echo "Arguments received: $*"
exec java -jar /usr/share/snpEff/snpEff/snpEff.jar "$@"
%post
# tmp folder for downloads and stuff
TMPDIR=/tmp/snpEff_download
# the installation directory of snpEff
INSTALLDIR=/usr/share/snpEff
# Installing JAVA 8 openjdk from the official centos repo
yum clean rpmdb
yum install -y java-1.8.0-openjdk wget unzip
# Prepare snpEff download and installation
mkdir -p $INSTALLDIR
# Download snpEff version 4.3p (2017-06-06)
wget -P $TMPDIR http://sourceforge.net/projects/snpeff/files/snpEff_v4_3p_core.zip
# uncomment this, if you want to use the latest version of snpEff
# wget -P $TMPDIR http://sourceforge.net/projects/snpeff/files/snpEff_latest_core.zip
# Unzip snpEff archive
ls $TMPDIR | xargs -i unzip "$TMPDIR/{}" -d $INSTALLDIR
# Remove tmp snpEff directory
rm -rf $TMPDIR
%test
java -jar /usr/share/snpEff/snpEff/snpEff.jar -version


Has anyone else looked into this?
I managed to get mine working yesterday...
The best bit is that the readings are in Wh so you can see each pulse.
Unfortunately it doesn't include the reverse register, just the kWh and kWArh registers.
I don't think all Ampy meters have this feature either.
The little black box on the right is my inductive pickup.
Re: Reading Ampy meters via the inductive serial port
FAB!
you simply have to give us more details!
What are he devices involved and sources of such devices?
this looks like exactly what i want
I'm tired of the current cost clamp being so badly accurate and reading FLAG registers might prove expensive and less flexible - unless someone knows different?
cheers
Re: Reading Ampy meters via the inductive serial port
Very nice! nice work!
A similar thing can be done with the A100C Elster meter's that are typically used with Solar PV installations in the UK but using an IR transistor instead to read from the IrDA port http://openenergymonitor.blogspot.co.uk/2012/08/reading-watt-hour-data-from-elster.html
Re: Reading Ampy meters via the inductive serial port
I'm interested in doing this. Do you have any details on the Loop Pickup sensor you used/made?
Is the information the same as you can get out of the IEC optical port? I have tried to get a readout of the opitcal port but it doesn't seem to provide any registers (it acknowledges my query but doesn't send any data). I'm hoping I might have more luck using the inductive port, but I can't find much info on how to make an inductive reader.
Re: Reading Ampy meters via the inductive serial port
The first thing to check is that your meter has an inductive serial port. If it's the same as mine, a 5192J, then obviously it does, if not then you need to hunt down a manual for your meter and check. The 5192J manual is very vague, it just says something like "the meter incorporates an inductive serial port which transmits data through the case". Everything else I had to work out for myself.
The circuit diagram for my homemade receiver is just on a scrap of paper at the moment but if your meter definitely has an inductive port and you want to go ahead then I'll make the effort to draw it out and post it here.
The data from the inductive port is the meter version and serial number followed by the 8 kWh registers and the 8 kVArh registers, all in ASCII hexadecimal.
The optical port has much more information and allows you to configure the meter but for that you will need the control software and password and messing with that is likely to get you into trouble with your service provider.
Re: Reading Ampy meters via the inductive serial port
Yeah, its the same meter. Any info you can provide on the pickup interface would be greatly appreciated!
Thanks
Re: Reading Ampy meters via the inductive serial port
I haven't got time to draw the circuit properly right now so I've attached a scan of my scrap of paper. Sorry about the scribble.
It's very simple, just an LC front end to act as a roughly tuned pickup followed by an amplification stage, a detector and a comparator. The output of the comparator can be fed directly into a 5V serial port but I included a resistor divider because I feed the output into an emonTx 3V serial port.
Here's a couple of photos of the prototype...
Re: Reading Ampy meters via the inductive serial port
Thanks! I've ordered the parts and i'll design my pcb tonight. Did you use PCBGCODE for your board?
Re: Reading Ampy meters via the inductive serial port
Did you use PCBGCODE for your board?
No, I used 2D PCB but the same process i.e using a milling machine.
I've attached the 2D PCB file in case it's any use to you and here's a screenshot in case it isn't...
Re: Reading Ampy meters via the inductive serial port
Hi, very interested in being able to record the meter usage. I found counting the light pulses wrong, as with solar generation I would get 1000s of pulses but no units.
I have succeeded with the circuit and have pulses going to my Arduino
But it makes no sense- I expected some ascii numbers but get rubbish
The drawing says 1200 baud but not the parity or stop bits or data size
I have found the position relative to the meter very critical - a few cm in any direction changes the signal
The meter is a Ampy 5192J
Attached is an xls of the signal from an oscilloscope
Any help would be appreciated
Mike
Re: Reading Ampy meters via the inductive serial port
Welcome, Mike,
MartinR hasn't been seen around here for a little while, so I'm not sure whether he'll see your question. If he doesn't respond, give me a prod and I'll try emailing him.
Have you tried interpreting the bytes as data rather than as characters - as unsigned long integers, for example?
Re: Reading Ampy meters via the inductive serial port
Hi, not had a response from MartinR, I would be grateful if you would email
I had no result with looking for byte data
Attached is a new trace showing the carrier wave (26hz)
Given that it should be on/off keying, it is difficult to see the "off" portion
Regards
Mike
Re: Reading Ampy meters via the inductive serial port
MartinR says:
The format is very simple, just on-off keying so you should see the ASCII output on any serial terminal. This is what a single line looks like....
AMP5165JA470507109 0014B4A4001488A700118265000000000000000000000000000000000000A792000B6343000B341C0009808C00000000000000000000000000000000000000B70811
I can’t remember what it all means off the top of my head but you should be able to work it out from the attached sketch. This is my initial sketch which uses a software serial port so that the decoded data can be sent via the hardware port. I haven’t looked at this sketch for a long time but I believe it works.
From the waveform that you captured, I'd suggest you need to experiment with the pickup - the tuning and damping. It might be that you have an excessive 'Q', meaning that the tuned coil continues to oscillate after the signal has been removed, and this is obscuring the 'off' periods. Adding a parallel resistor should help. I assume you've tuned the pickup for the correct carrier frequency.
Attached is his initial sketch. For his final version, MartinR says he integrated the Ampy meter reading code into his 3-phase code and used one of the hardware serial ports to read the meter and send the readings via radio to the emonGLCDs etc.


?6
7
8
9
10
T
M
v
The
NEwYbRK
copyright
reserved
botanical
Garden
THE
NEW
YORK
BOTANICAL
GARDEN
Plants
of
Hispaniola
Dominican
Republic
15882
Herbaceous,
growing
in
clumps;
glumes
pale
green;
on
grassy
slope,
in
open
pine
forest.
Pinelands
on
serpentine
and
lateritic
soil.
About
4
miles
S
from
La
Vega.
Alt.
200-500
m.
Bro.
Alain
H.
Liogier
27
Jun
1969
Supported
by
funds
from
the
National
Science
Foundation.
1604602
Legend -
Level of confidence that token is an accurately-transcribed word
extremely low
very low
low
undetermined
medium
high
very high


Supporting you every step of the way
Need some information? Tell us about it by using the form below.
You have indicated an interest in the following resources. Please click on the links to learn more about these resources.


This page will refresh every 5 seconds. This is because we're using the 'onload' event to call our function. We are passing in the value '5000', which equals 5 seconds.
But hey, try not to annoy your users too much with unnecessary page refreshes every few seconds!
Last Update: 4/14/13


to setup a hotkey select
"New" from the toolbar and fill in the dialog that pops up.
to assign keyboard keys select the
"Hotkey" box in the dialog and start typing the
desired keys or key combinations on your keyboard.
the keys you entered may look funny. "<LeftControl+Oem-Period>" for example. this is because
TableCrab is too lazy to look up the keys as they read on your keyboard. use the
"Hotkey Name"
box to overwrite with a name of your choice. for the above key "LeftCtrl+Period" could be a nice name.
some special keys can be found in the dropdown of the
"Hotkey" box:
- MouseWheelUp - triggers the action when the mouse wheel is scolled upwards
- MouseWheelDown - - triggers the action when the mouse wheel is scolled downwards
- keys that would trigger actions in the dialog when you would try to enter them
you can always go back to entering keys directly from your keyboard by selecting the first
item in the dropdown.
- you can setup up to 64 hotkeys
- "LeftControl" is "left control key". that is left not right. same goes for all
other keys that have left and a right representation on your keyboard.
- TableCrab does not check for conflicting hotkeys. it always takes the first one in the list if in doubt.
- you can not assign the following keys: Shift, Scroll, Numlock and
Capital. TableCrab ignores these keys and does not know if they are locked on your keyboard
or not.
- hotkeys are disabled as long as the mouse is over the chat or notes box.


Class: WsdlMapperTesting::GenerationTest
- Inherits:
-
SchemaTest
- Object
- Minitest::Test
- Test
- SchemaTest
- WsdlMapperTesting::GenerationTest
- Defined in:
- lib/wsdl_mapper_testing/generation_test.rb
Instance Method Summary (collapse)
- - (Object) assert_file_contains(*name, expected)
- - (Object) assert_file_exists(*name)
- - (Object) assert_file_is(*name, expected)
- - (Object) context
- - (Object) file(*name)
- - (Object) path_for(*name)
- - (Object) setup
- - (Object) teardown
- - (Object) tmp_path
Methods inherited from SchemaTest
Methods inherited from Test
Instance Method Details
- (Object) assert_file_contains(*name, expected)
31 32 33 34 35 36 37 |
# File 'lib/wsdl_mapper_testing/generation_test.rb', line 31 def assert_file_contains(*name, expected) assert_file_exists *name content = file(*name) content_normalized = content.gsub(/^\s+/, '') expected_normalized = expected.strip.gsub(/^\s+/, '') assert content_normalized.include?(expected_normalized), "Expected\n\n#{content}\n\n to include\n\n#{expected}\n" end |
- (Object) assert_file_exists(*name)
21 22 23 24 |
# File 'lib/wsdl_mapper_testing/generation_test.rb', line 21 def assert_file_exists(*name) path = tmp_path.join *name assert File.exist?(path), "Expected file #{name * '/'} to exist." end |
- (Object) assert_file_is(*name, expected)
26 27 28 29 |
# File 'lib/wsdl_mapper_testing/generation_test.rb', line 26 def assert_file_is(*name, expected) assert_file_exists *name assert_equal expected, file(*name) end |
- (Object) context
43 44 45 |
# File 'lib/wsdl_mapper_testing/generation_test.rb', line 43 def context @context ||= WsdlMapper::Generation::Context.new @tmp_path.to_s end |
- (Object) file(*name)
39 40 41 |
# File 'lib/wsdl_mapper_testing/generation_test.rb', line 39 def file(*name) File.read tmp_path.join *name end |
- (Object) path_for(*name)
17 18 19 |
# File 'lib/wsdl_mapper_testing/generation_test.rb', line 17 def path_for(*name) tmp_path.join *name end |
- (Object) setup
5 6 7 |
# File 'lib/wsdl_mapper_testing/generation_test.rb', line 5 def setup @tmp_path = TestHelper.get_tmp_path end |
- (Object) teardown
9 10 11 |
# File 'lib/wsdl_mapper_testing/generation_test.rb', line 9 def teardown @tmp_path.unlink end |
- (Object) tmp_path
13 14 15 |
# File 'lib/wsdl_mapper_testing/generation_test.rb', line 13 def tmp_path @tmp_path end |


Bing Crosby's Unseen Wartime Letters And Photographs Discovered
The actor and singer's previously unseen documents were discovered in a California attic.
(Picture: Decca Records).
Letters sent by Bing Crosby to families of the Second World War soldiers have been released for the first time.
Photographs of the late US music star and actor entertaining troops have also come to light after being discovered in his California attic.
In one letter, typed on paper headed 'Bing Crosby, Hollywood' and dated 10 April 1945, the musician wrote: "It was a pleasure working for the boys in France and Belgium, in fact, one of the richest experiences of my life."
In some of the letters, he told the soldiers families that he had met their loved ones.
In correspondence, the families replied thanking the singer for bringing joy and hope to their sons, husbands and brothers.
Beth Du Bois was one of the mothers who wrote to Mr Crosby, dates March 5, 1944, she said: "It gives me a strangely comforting feeling to know that someone whose voice I can hear has so recently talked with my son whom I have not seen for almost two years.
"It brings them nearer somehow."
The photographs show Bing singing to crowds of soldiers in England, France and Belgium, as well as performing shows at the front line.
Bing Crosby was one of the most recorded performers in history.
In a letters, sent to Mrs. Philip K, Lawler, dated February 28, 1941, Mr Crosby wrote: "You were very nice to send me excerpts from your husband’s letter written in France and describing our show there for the mighty 79th Division.
"I’m going to keep this letter handy because it provides an exact reminder of our routine overseas, and when anyone asks me what we did, I need only to whip it out, and let them read the complete details.
"The audience was the greatest I ever faced - warm, receptive, eager and we left there entirely conscious that we'd just been given a rare privilege, the privilege of bringing even a small touch of home, a few laughs and some sighs to a wonderful bunch of men during a sensational job."
During his lifetime, Mr Crosby won the Academy Award as Best Actor for his performance in ‘Going My Way’, in 1944.
Robert S Bader, who is vice president of the company in charge of Bing Crosby's estate, said he was "overwhelmed" by finding the letters and photographs.
"He kept these deeply personal letters in a safe place apart from everything else," Mr Bader said.
"The letters from the soldiers' family members are often heartbreaking.
"These people felt such a deep connection to this man they only knew as a famous entertainer.
"And he lived up to their faith in him with equally heartfelt letters back to them."


How to conduct a journalistic interview
Assembly time: Will vary per interview
Awesome rating: 1,000,000% awesome
Are you a new journalist trying to learn good interviewing techniques? This is the page for you!
-
Do research beforehand.
To be well-informed during your interview, learn as much as you can about your interview subject and the topic you will be discussing before speaking with them. While the internet can be a quick way to get information, be sure that your sources are credible. Double check information with several sources, or refer to peer-reviewed, academic sources (e.g. scholarly journals).
-
Find what has been overlooked.
If you are interviewing a public figure who has conducted other interviews, refer to those discussions and look for a missing link in the narrative. While other interviewers may opt to ask the same, buzz-worthy questions and yield the same results, you can conduct an original interview by asking about something they’ve overlooked.
-
Record the interview
Having a recording of your interview will vastly improve your chances of accurately representing the discussion later on. Record the interview on your smart phone, or using a simple tape recorder. Note that you must ask your interview subject’s permission before recording any conversation you have with them.
-
Make the interview seem casual.
To set your respondent at ease, make the interview seem as casual as possible. Beforehand, refer to the interview as an opportunity for you to talk with them (as opposed to interviewing them), which will put less pressure on them as the designated subject. Be friendly and kind, and allow them to see any nervousness you may be feeling as well.
-
Take detailed notes.
Whether or not you are recording your interview electronically, take notes about other details of the conversation. These may include distinguishing features of the interviewee, things that were happening in the background during the interview, or notable emotional reactions to certain questions. If you can’t record these details during the interview, write them down immediately following it while the experience is still fresh in your mind.