Author: 199opwmai497

MI BCI Analysis

Analysis of data collected during a 3-day Motor Imagery (MI) Brain-Computer Interface (BCI) experiment involving 8 healthy participants.

MATLAB Toolbox

`biosig`

disp('[config] - Adding biosig toolbox');
addpath(genpath('<absolute-path>\mi-bci-analysis\toolbox\biosig\biosig\t200_FileAccess'));
addpath(genpath('<absolute-path>\mi-bci-analysis\toolbox\biosig\biosig\t250_ArtifactPreProcessingQualityControl'));

% NOTE: Toolbox version may be different

`eeglab`

disp('[config] - Adding eeglab toolbox');
addpath(genpath('<absolute-path>\mi-bci-analysis\toolbox\eeglab\eeglab2024.2'));

% NOTE: Toolbox version may be different

Dataset

The data was recorded using a 16-channel EEG amplifier at a sampling rate of 512 Hz, where the electrodes were positioned according to the 10-20 international system.

Each participant completed at least two recording days:

Day 1: 3 “offline” runs (calibration, without real feedback) and 2 “online” runs
(with real feedback);
Day 2 and Day 3: 2 “online” runs per day.

Resource

https://cloud.dei.unipd.it/index.php/s/DLJfJccgFnFiDZY

Instructions

Create toolbox/ folder in root directory and insert biosig and eeglab toolboxes
Create dataset/ folder in root directory and insert micontinuous dataset
Run generation.m script
Run analysis.m script
Run selection.m script
Run training.m script
Run evaluation.m script

Tested Environments

Local machine, Windows 11, MATLAB R2024b
Local machine, MacOS Sequoia, MATLAB R2024b
Local machine, Windows 11, MATLAB R2023a
Local machine, Windows 11, MATLAB R2023b

Authors

Federico Pivotto, 2121720, federico.pivotto@studenti.unipd.it
Alessandro Bozzon, 2122185, alessandro.bozzon@studenti.unipd.it
Riccardo Simion, 2157564, riccardo.simion@studenti.unipd.it
Riccardo Zerbinati, 2158676, riccardo.zerbinati@studenti.unipd.it

Contributions

Member	Workload	Work
Federico Pivotto	25%	Project structure, data generation, training workflow, evaluation workflow, feature selection, selection workflow, model training and evalutation chapter in report
Alessandro Bozzon	25%	Topoplot computation, analysis workflow, feature selection, performance metrics, topoplot chapter in report
Riccardo Simion	25%	Spectrogram computation, model training, feature selection, spectrogram chapter in report
Riccardo Zerbinati	25%	Feature map computation, model evaluation, feature selection, feature map chapter in report

android-rtlmarqueeview

Use RtlMarqueeView to display rtl (or ltr) text with proper movement direction.

Based on open source lib: https://github.com/MohMah/MarqueeView under the MIT License.

Preview:

Integration

Add it in your root build.gradle at the end of repositories:

	allprojects {
		repositories {
			...
			maven { url 'https://jitpack.io' }
		}
	}

Add the dependency:

	dependencies {
		compile 'com.github.shachar-oren:android-rtlmarqueeview:1.0.5'
	}

Usage

Example usage in XML:

<RelativeLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    xmlns:rtlmrq="http://schemas.android.com/apk/res-auto"
    tools:context=".MainActivity"
    android:layout_margin="16dp">

    <com.shacharsoftware.rtlmarqueeview.RtlMarqueeView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_centerVertical="true"
        android:scrollbars="none"
        android:id="@+id/rmv_marquee"
        android:layout_centerInParent="true"
        rtlmrq:marqueeTextSize="18dp"
        rtlmrq:marqueeText="@string/example_sentence"
        rtlmrq:marqueeEndWaitTicks="30"
        rtlmrq:marqueeFadeToColor="@color/white"
        rtlmrq:marqueeIsLooping="true"
        rtlmrq:marqueeStartWaitTicks="30"
        rtlmrq:marqueeLoops="0"
        rtlmrq:marqueeTextColor="@color/colorPrimary"
        />

</RelativeLayout>

Layout direction is checked internally. To manually update it, call updateRtl().

Public methods:

void setText(String text)
String getText()
void setTextColor(int color)
int getTextColor()
void setTextSize(float size)
float getTextSize()
void setFadeToColor(int color)
int getFadeToColor()
void setLooping(boolean looping)
boolean getLooping()
void setLoops(int loops)
int getLoops()
void setStartWaitTicks(int ticks)
int getStartWaitTicks()
void setEndWaitTicks(int ticks)
int getEndWaitTicks()

License

Copyright 2017 Shachar Oren

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

GitLab Merge Request Concourse Resource

A concourse resource to check for new merge requests on GitLab and update the merge request status.

Source Configuration

resource_types:
- name: merge-request
  type: docker-image
  source:
    repository: mastertinner/gitlab-merge-request-resource

resources:
- name: repo-mr
  type: merge-request
  source:
    uri: https://gitlab.com/myname/myproject.git
    private_token: XXX
    username: my_username
    password: xxx

uri: The location of the repository (required)
private_token: Your GitLab user’s private token (required, can be found in your profile settings)

private_key: The private SSH key for SSH auth when pulling

Example:

private_key: |
  -----BEGIN RSA PRIVATE KEY-----
  MIIEowIBAAKCAQEAtCS10/f7W7lkQaSgD/mVeaSOvSF9ql4hf/zfMwfVGgHWjj+W
  <Lots more text>
  DWiJL+OFeg9kawcUL6hQ8JeXPhlImG6RTUffma9+iGQyyBMCGd1l
  -----END RSA PRIVATE KEY-----

username: The username for HTTP(S) auth when pulling
password: The password for HTTP(S) auth when pulling
no_ssl: Set to true if the GitLab API should be used over HTTP instead of HTTPS
skip_ssl_verification: Optional. Connect to GitLab insecurely – i.e. skip SSL validation. Defaults to false if not provided.

Please note that you have to provide either private_key or username and password.

Behavior

`check`: Check for new merge requests

Checks if there are new merge requests or merge requests with new commits.

`in`: Clone merge request source branch

git clones the source branch of the respective merge request.

`out`: Update a merge request’s merge status

Updates the merge request’s merge_status which displays nicely in the GitLab UI and allows to only merge changes if they pass the test.

Parameters

repository: The path of the repository of the merge request’s source branch (required)
status: The new status of the merge request (required, can be either pending, running, success, failed, or canceled)
build_label: The label of the build in GitLab (optional, defaults to "Concourse")

Example

jobs:
- name: test-merge-request
  plan:
  - get: repo
    resource: repo-mr
    trigger: true
  - put: repo-mr
    params:
      repository: repo
      status: running
  - task: run-tests
    file: repo/ci/tasks/run-tests.yml
  on_failure:
    put: repo-mr
    params:
      repository: repo
      status: failed
  on_success:
    put: repo-mr
    params:
      repository: repo
      status: success

E-REKRUTMEN

Website Rekrutmen Terbaru Bisa Dilihat Di Repositori: https://github.com/soden46/Rekrutmen-KP-Laravel-9

Demo Bisa Dilihat Di: https://lokercafe.000webhostapp.com/

Dukung Saya di: Syarif Soden

Myth:Auth

Flexible, Powerful, Secure auth package for CodeIgniter 4.

Project Notice

As of June 2022 CodeIgniter now has an official Authentication library, CodeIgniter Shield. If you are looking for an authentication solution for a new project then that is the recommended solution.

This project is now maintained by volunteers. If you interact with the project repository there may be delays in receiving response. Please direct support questions to GitHub Discussions or to CodeIgniter’s Forums or Slack Channel.

Requirements

PHP 7.4+, 8.0+
CodeIgniter 4.1+

Features

This is meant to be a one-stop shop for 99% of your web-based authentication needs with CI4. It includes the following primary features:

Password-based authentication with remember-me functionality for web apps
Flat RBAC per NIST standards, described here and here.
All views necessary for login, registration and forgotten password flows.
Publish files to the main application via a CLI command for easy customization
Debug Toolbar integration
Email-based account verification

Installation

Installation is best done via Composer. Assuming Composer is installed globally, you may use the following command:

    > composer require myth/auth

This will add the latest stable release of Myth:Auth as a module to your project.

Manual Installation

Should you choose not to use Composer to install, you can clone or download this repo and then enable it by editing app/Config/Autoload.php and adding the Myth\Auth namespace to the $psr4 array. For example, if you copied it into app/ThirdParty/:

    $psr4 = [
        'Config'      => APPPATH . 'Config',
        APP_NAMESPACE => APPPATH,
        'App'         => APPPATH,
        'Myth\Auth'   => APPPATH . 'ThirdParty/myth-auth/src',
    ];

Upgrading

Be sure to check the Changes Docs for necessary steps to take after upgrading versions.

Configuration

Once installed you need to configure the framework to use the Myth\Auth library. In your application, perform the following setup:

Edit app/Config/Email.php and verify that a fromName and fromEmail are set as that is used when sending emails for password reset, etc.
Edit app/Config/Validation.php and add the following value to the ruleSets array: \Myth\Auth\Authentication\Passwords\ValidationRules::class
Ensure your database is setup correctly, then run the Auth migrations:

    > php spark migrate -all

NOTE: This library uses your application’s cache settings to reduce database lookups. If you want to make use of this, simply make sure that your are using a cache engine other than dummy and it is properly setup. The GroupModel and PermissionModel will handle caching and invalidation in the background for you.

Overview

When first installed, Myth:Auth is setup to provide all of the basic authentication services for you, including new user registration, login/logout, and forgotten password flows.

“Remember Me” functionality is turned off by default though it can be turned on by setting the $allowRemembering variable to be true in Config/Auth.php.

Routes

Routes are defined in Auth’s Config/Routes.php file. This file is automatically located by CodeIgniter when it is processing the routes. If you would like to customize the routes, you should copy the file to the app/Config directory, update the namespace, and make your route changes there. You may also use the $reservedRoutes property of Config\Auth to redirect internal route names.

Views

Basic views are provided that are based on Bootstrap 4 for all features.

You can easily override the views used by editing Config/Auth.php, and changing the appropriate values within the $views variable:

public $views = [
    'login'       => 'Myth\Auth\Views\login',
    'register'    => 'Myth\Auth\Views\register',
    'forgot'      => 'Myth\Auth\Views\forgot',
    'reset'       => 'Myth\Auth\Views\reset',
    'emailForgot' => 'Myth\Auth\Views\emails\forgot',
];

NOTE: If you’re not familiar with how views can be namespaced in CodeIgniter, please refer to the CodeIgniter User Guide for section on Code Module support.

Services

The following Services are provided by the package:

authentication

Provides access to any of the authentication packages that Myth:Auth knows about. By default it will return the “Local Authentication” library, which is the basic password-based system.

    $authenticate = service('authentication');

You can specify the library to use as the first argument:

    $authenticate = service('authentication', 'jwt');

authorization

Provides access to any of the authorization libraries that Myth:Auth knows about. By default it will return the “Flat” authorization library, which is a Flat RBAC (role-based access control) as defined by NIST. It provides user-specific permissions as well as group (role) based permissions.

    $authorize = service('authorization');

passwords

Provides direct access to the Password validation system. This is an expandable system that currently supports many of NIST’s latest Digital Identity guidelines. The validator comes with a dictionary of over 620,000 common/leaked passwords that can be checked against. A handful of variations on the user’s email/username are automatically checked against.

    $authenticate = service('passwords');

Most of the time you should not need to access this library directly, though, as a new Validation rule is provided that can be used with the Validation library, strong_password. In order to enable this, you must first edit app/Config/Validation.php and add the new ruleset to the available rule sets:

     public $ruleSets = [
        \CodeIgniter\Validation\Rules::class,
        \CodeIgniter\Validation\FormatRules::class,
        \CodeIgniter\Validation\FileRules::class,
        \CodeIgniter\Validation\CreditCardRules::class,
        \Myth\Auth\Authentication\Passwords\ValidationRules::class,
    ];

Now you can use strong_password in any set of rules for validation:

    $validation->setRules([
        'username' => 'required',
        'password' => 'required|strong_password'
    ]);

Helper Functions

Myth:Auth comes with its own Helper that includes the following helper functions to ease access to basic features. Be sure to load the helper before using these functions: helper('auth');

Hint: Add 'auth' to any controller’s $helper property to have it loaded automatically, or the same in app/Controllers/BaseController.php to have it globally available. the auth filters all pre-load the helper so it is available on any filtered routes.

logged_in()

Function: Checks to see if any user is logged in.
Parameters: None
Returns: true or false

user()

Function: Returns the User instance for the current logged in user.
Parameters: None
Returns: The current User entity, or null

user_id()

Function: Returns the User ID for the current logged in user.
Parameters: None
Returns: The current User’s integer ID, or null

in_groups()

Function: Ensures that the current user is in at least one of the passed in groups.
Parameters: Group IDs or names, as either a single item or an array of items.
Returns: true or false

has_permission()

Function: Ensures that the current user has at least one of the passed in permissions.
Parameters: Permission ID or name.
Returns: true or false

Users

Myth:Auth uses CodeIgniter Entities for it’s User object, and your application must also use that class. This class provides automatic password hashing as well as utility methods for banning/un-banning, password reset hash generation, and more.

It also provides a UserModel that should be used as it provides methods needed during the password-reset flow, as well as basic validation rules. You are free to extend this class or modify it as needed.

The UserModel can automatically assign a role during user creation. Pass the group name to the withGroup() method prior to calling insert() or save() to create a new user and the user will be automatically added to that group.

    $user = $userModel
                ->withGroup('guests')
                ->insert($data);

User registration already handles this for you, and looks to the Auth config file’s, $defaultUserGroup setting for the name of the group to add the user to. Please, keep in mind that $defaultUserGroup variable is not set by default.

Toolbar

Myth:Auth includes a toolbar collector to make it easy for developers to work with and troubleshoot the authentication process. To enable the collector, edit app/Config/Toolbar.php and add it to the list of active collectors:

	public $collectors = [
		\CodeIgniter\Debug\Toolbar\Collectors\Timers::class,
		\CodeIgniter\Debug\Toolbar\Collectors\Database::class,
        ...
		\Myth\Auth\Collectors\Auth::class,
	];

Restricting by Route

If you specify each of your routes within the app/Config/Routes.php file, you can restrict access to users by group/role or permission with Controller Filters.

First, edit application/Config/Filters.php and add the following entries to the aliases property:

    'login'      => \Myth\Auth\Filters\LoginFilter::class,
    'role'       => \Myth\Auth\Filters\RoleFilter::class,
    'permission' => \Myth\Auth\Filters\PermissionFilter::class,

Global restrictions

The role and permission filters require additional parameters, but LoginFilter can be used to restrict portions of a site (or the entire site) to any authenticated user. If no logged in user is detected then the filter will redirect users to the login form.

Restrict routes based on their URI pattern by editing app/Config/Filters.php and adding them to the $filters array, e.g.:

public filters = [
    'login' => ['before' => ['account/*']],
];

Or restrict your entire site by adding the LoginFilter to the $globals array:

    public $globals = [
        'before' => [
            'honeypot',
            'login',
    ...

Restricting a single route

Any single route can be restricted by adding the filter option to the last parameter in any of the route definition methods:

$routes->get('admin/users', 'UserController::index', ['filter' => 'permission:manage-user'])
$routes->get('admin/users', 'UserController::index', ['filter' => 'role:admin,superadmin'])

The filter can be either role or permission, which restricts the route by either group or permission. You must add a comma-separated list of groups or permissions to check the logged in user against.

Restricting Route Groups

In the same way, entire groups of routes can be restricted within the group() method:

$routes->group('admin', ['filter' => 'role:admin,superadmin'], function($routes) {
    ...
});

Customization

See the Extending documentation.

CodeIgniter 4 Development

What is CodeIgniter?

CodeIgniter is a PHP full-stack web framework that is light, fast, flexible and secure. More information can be found at the official site.

This repository holds the source code for CodeIgniter 4 only. Version 4 is a complete rewrite to bring the quality and the code into a more modern version, while still keeping as many of the things intact that has made people love the framework over the years.

More information about the plans for version 4 can be found in the announcement on the forums.

Documentation

The User Guide is the primary documentation for CodeIgniter 4.

The current in-progress User Guide can be found here. As with the rest of the framework, it is a work in progress, and will see changes over time to structure, explanations, etc.

You might also be interested in the API documentation for the framework components.

Important Change with index.php

index.php is no longer in the root of the project! It has been moved inside the public folder, for better security and separation of components.

This means that you should configure your web server to “point” to your project’s public folder, and not to the project root. A better practice would be to configure a virtual host to point there. A poor practice would be to point your web server to the project root and expect to enter public/…, as the rest of your logic and the framework are exposed.

Please read the user guide for a better explanation of how CI4 works!

Repository Management

CodeIgniter is developed completely on a volunteer basis. As such, please give up to 7 days for your issues to be reviewed. If you haven’t heard from one of the team in that time period, feel free to leave a comment on the issue so that it gets brought back to our attention.

We use GitHub issues to track BUGS and to track approved DEVELOPMENT work packages. We use our forum to provide SUPPORT and to discuss FEATURE REQUESTS.

If you raise an issue here that pertains to support or a feature request, it will be closed! If you are not sure if you have found a bug, raise a thread on the forum first – someone else may have encountered the same thing.

Before raising a new GitHub issue, please check that your bug hasn’t already been reported or fixed.

We use pull requests (PRs) for CONTRIBUTIONS to the repository. We are looking for contributions that address one of the reported bugs or approved work packages.

Do not use a PR as a form of feature request. Unsolicited contributions will only be considered if they fit nicely into the framework roadmap. Remember that some components that were part of CodeIgniter 3 are being moved to optional packages, with their own repository.

Contributing

We are accepting contributions from the community! It doesn’t matter whether you can code, write documentation, or help find bugs, all contributions are welcome.

Please read the Contributing to CodeIgniter.

CodeIgniter has had thousands on contributions from people since its creation. This project would not be what it is without them.

Made with contrib.rocks.

Server Requirements

PHP version 7.4 or higher is required, with the following extensions installed:

intl
libcurl if you plan to use the HTTP\CURLRequest library
mbstring

Additionally, make sure that the following extensions are enabled in your PHP:

json (enabled by default – don’t turn it off)
xml (enabled by default – don’t turn it off)
mysqlnd

Running CodeIgniter Tests

Information on running the CodeIgniter test suite can be found in the README.md file in the tests directory.

E-REKRUTMEN

do_DogLcd

This is a port enabling use of the Electronic Assembly DOGM Character LCD displays using hardware SPI with the Particle Core and Photon. The code also works with Arduino.

6.14.15 version 0.1

6.15.15 version 0.1.8

This code has only been tested using a DOGM162W-A display (black on white, 16×2 lines, no backlight). Other variations of the display (1 line, 3 line) have NOT been tested.

6.15.15
The Library has been tested using a Spark Core with hardware or software SPI at 3V3, and tested using an Arduino Uno with hardware or software SPI at 5V. In both cases, it works fine, pretty much. There’s a HelloWorld example program that demonstrates various behaviors.

The contrast/gain settings were scanned to find values that work well – at 3V3, the display is VERY sensitive to the Gain and Contrast – too low and you see nothing, too high and you see black boxes. Good values for 3V3 in my hands are Gain 3, Contrast 50. At 5V, the display seems much more robust to the settings, but a good choice seems to be Gain 2, Contrast 40. These values are used as defaults.

V 0.1.8 Spark/Arduino code is in /firmware. I’m trying to figure out how to set this up for easiest access for Arduino vs Particle library management. Arduino specific stuff is in /Arduino. This is to be cleaned up.

The Library is based on and includes much of the code from the DogLcd Library written by Eberhard Fahle (https://github.com/wayoda/DogLcd) with adaptations from the dogm_7036 Library provided by ELECTRONIC ASSEMBLY (http://www.lcd-module.com/support/application-note/arduino-meets-ea-dog.html) and the SparkCore-LiquidCrystalSPI Library written by BDub (https://github.com/technobly/SparkCore-LiquidCrystalSPI)

Changes include –

modifications to allow hardware SPI
addition of setGain to allow software setting of the LCD amplification ratio (works with Contrast to determine whether you see anything on the display, or see ‘black boxes’).
user inputs contrast and gain (if desired) over integer range 0-63 and 0-7, respectively.
restructuring of the initialization code to make hardware and voltage dependent parameter settings more explicit.
flag to prevent hardware reset if user has added new characters (deleted during the reset, otherwise).
added #if defined(SPARK) and #if defined(ARDUINO) statements to allow the library to work with both platforms. seems to behave as expected.
heavily commented due to being a library/hardware n00b.

EA DOGM documentation is available here: http://www.lcd-module.de/fileadmin/eng/pdf/doma/dog-me.pdf. The display controller documentation is available here: http://www.lcd-module.de/eng/pdf/zubehoer/st7036.pdf

http://jaldilabs.org

SlushFlicks

SlushFlicks has been built upon public APIs from IMDB. This application helps users to view trending, popular, upcoming and top-rated movies and Tv shows and their detailed information. Users can also search for a movie or Tv show. This app also cache data to support offline browsing. This is a personal project and the core objective of this project was to have hands-on experience on recent Android jetpack library components like navigation, paging and MVI architecture. In addition to this, Local unit testing is also being implemented in this project. Furthermore, worked on optimization by eliminating memory leaks and reducing gpu-overdraw.

Architecture

MVI architecture has been followed in this project where the View is producing Events (Intent) based on user interaction. When ViewModel receives these event it updates the ViewState to show loading state if necessary and observe for data from the Repository. Repository responds to the request with either Success or Error and upon receiving the response ViewModel update the ViewState accordingly. As the View is observing for the ViewState, it eventually gets notified about the response and show relevant information to the user.

ViewState: ViewState can be considered as the snapshot of the current state of the screen.
Event: Events are being fired from the screen based on user interaction.
ViewEvent: When ViewState changes it fires the ViewEvents which eventually reflects the changes to the user on the screen.

Resource

Resources can be stated as a set of strategies that have been used by the Repository to provide data to the ViewModel. The strategies followed in this project are mentioned below:

CacheFirstNetworkUpdateResource: Provide the data from the cache immediately. Then look for any update in the network. As soon as the updated data is being retrieved, update the cache. In case of using Room database, if the Query was being observed, the updated data will be reflected in the UI immediately.
NetworkFirstCacheUpdateResource: This resource will first try to provide data from the network and update the cache, if fails to do so(ex: no internet connection), will provide the data from cache(local database)
CacheOnlyResource: A the name suggests, this resource will provide. data only from the cache.
NetworkOnlyResource: In contrast to CacheOnlyResource, this resource will provide data only from the network.
CacheUpdateResource: This resource is used to keep the cached data update.

DataManager

As the Facade design pattern suggests, to create an abstraction layer on top to hide the internal complex implementation. DataManager works as an abstraction layer on top of the local data storage system. As local data can be saved in Database, SharedPreference or even in the asset folder in different files, DataManager provides a simple interface, hiding the information about the actual storage location of data. It also enhances the scalability, as new Local Storage can be added in the future with minimal change.

DatabaseManager: Provides data from local database
LocalDataManager: Provides non-persistent data. Data that is essential to the different states of the application can be kept here to ensure faster access.
SharedPrefManager: Provides data from SharedPreference
FireStoreManager: Provides data from firestore. As firestore manages a persistent database for itself and data can be accessed locally from firestore, it has been kept here in the DataManager.

ErrorParser

ErrorParser comes into the picture to parse the error responses from the server separately. An ApiTag has been associated with each endpoint. With the help of this API tag and status code from the response, ErrorParser parse error effectively from the error body. As different API endpoints can provide different error responses with the same status code, ApiTag plays a vital role to add more flexibility on error parsing.

ErrorMapper (Future Work)

Different error messages need a different way to be handled in the UI. For example, some messages can be shown as Toast and Snackbar whereas, some needed to be shown as AlertDialog or BottomSheetDialog. With the help of ErrorMapper ViewModel can map these actions to a specific error response.

Optimization

Memory leak: Leak canary has been used to identify and resolve most of the memory leaks.
GPU Overdraw optimization: GPU Overdrawn has been reduced by using Development Tools (like Layout Inspector, Debug GPU overdraw).

Cloudhus

Cloudhus central authentication, cloud service for Project-Hus which provides various features for lots of fields.

.
├── makefile                    <-- Make to automate build
├── README.md                   <-- This instructions file
├── services                    <-- Microservices
│   └── hus-auth                <-- Auth service
└── template.yaml              <-- SAM template

Fully Automated Single Sign-On Feature

SSO demo page

1. Before you visit any of our services, visit "SSO demo page" above.
and you're gonna see the page below.

2. Now click the link and visit "Lifthus", and then come back immediately to SSO demo.
if you refresh the page, you're gonna see this page.
Which means that your sessions are established and that they are connected to each other.

3. Go to Lifthus, and sign in. you will see this, when you come back and refresh.
Which means that you signed in to two different domains at the same time.

4. Finally, try signing out from Lifthus. you will see the 2nd pic again.
Which means that you are signed out from two different domains at the same time.

Sequence diagrams

CASE 1: when user connects without any valid tokens.

CASE 2: when user connects with a valid token.

CASE 3: when user signs in.

CASE 4: when user signs out.

Requirements

Docker
AWS CLI with Administrator permission
SAM CLI – Install the SAM CLI
Golang
Makefile

Setup process

Installing dependencies & building the target

“swag init” from hus-auth
“make build” from root

Local development

Invoking function locally through local API Gateway

sam local start-api

If the previous command ran successfully you should now be able to hit the following local endpoint to invoke your function http://localhost:3000/

make start

If the previous command ran successfully you should now be able to hit the following local endpoint to invke your function ‘http://localhost:9090‘

Running in native language runtime

# hus-auth
make go

Packaging and deployment

Every build and packaging is done by SAM CLI but NestJS must be transpiled to JS before packaging. Currently this job is done by Makefile. We are migrating to esbuild transpiling which SAM supports natively.

To deploy your application for the first time, run the following in your shell:

sam deploy --guided

The command will package and deploy your application to AWS, with a series of prompts:

Stack Name: The name of the stack to deploy to CloudFormation. This should be unique to your account and region, and a good starting point would be something matching your project name.
AWS Region: The AWS region you want to deploy your app to.
Confirm changes before deploy: If set to yes, any change sets will be shown to you before execution for manual review. If set to no, the AWS SAM CLI will automatically deploy application changes.
Allow SAM CLI IAM role creation: Many AWS SAM templates, including this example, create AWS IAM roles required for the AWS Lambda function(s) included to access AWS services. By default, these are scoped down to minimum required permissions. To deploy an AWS CloudFormation stack which creates or modifies IAM roles, the CAPABILITY_IAM value for capabilities must be provided. If permission isn’t provided through this prompt, to deploy this example you must explicitly pass --capabilities CAPABILITY_IAM to the sam deploy command.
Save arguments to samconfig.toml: If set to yes, your choices will be saved to a configuration file inside the project, so that in the future you can just re-run sam deploy without parameters to deploy changes to your application.

You can find your API Gateway Endpoint URL in the output values displayed after deployment.

Testing

No tests yet.

vault-plugin-auth-cloudfoundry

This is a standalone backend authentication plugin for use with HashiCorp Vault.
This plugin allows for applications running in Cloudfoundry using Instance Identity to authenticate with Vault.

Background

CF

Cloud Foundry can be enabled to provide instance credentials to its apps (Enabling Instance Identity).
Once enabled, Cloud Foundry injects into each app’s file system a unique x.509 certificate and RSA private key (referenced by $CF_INSTANCE_CERT and $CF_INSTANCE_KEY respectively).
This key-pair is updated regularly and automatically by Cloud Foundry, with a relatively short certificate TTL (eg 24 hours).

The public certificate contains fields identifying the app’s:

CF Org GUID
CF Space GUID
CF Instance GUID

More information: Using Instance Identity Credentials.

Vault

Vault provides a mechanism to create custom authentication plugins. These plugins typically authenticate users through use of cryptography and an established form of trust.
The plugin runs as a separate process on the same host as the main Vault process. Communication is via gRPC.

More information: Vault: Building Plugin Backends.

A common difficulty when using Vault is how to bootstrap applications with the required credentials needed to authenticate. This can introduce complexity and security concerns
into CI/CD pipelines and/or other deployment mechanisms, since they then become responsible for distribution of credentials.

Design

A Vault authentication plugin that would allow Cloud Foundry apps to authenticate using the Cloudy Foundry Instance Identity system. Apps would not need to be bootstrapped with
credentials. Instead, they would use the certificates provided by Cloud Foundry to authenticate themselves and gain access to Vault secrets.

Authentication Flow

A Vault admin enables the Cloud Foundry Vault authentication plugin, and configures it to trust the Cloud Foundry certificate authority. This is a one-time configuration step.
The Cloud Foundy app generates a JWT token. The token contains the app’s public certificate using the x5c field. The token
is signed using the app’s private key. The JWT token is signed using the app’s CF key pair.
The app makes an authentication request to Vault. Included in the request is the JWT token created in the previous step.
Vault recognizes the request as a Cloud Foundry authentication request and delegates to the plugin. The plugin processes the request and validates the following:
- App’s certificate was signed by the configured CA
- App’s certificate has not expired
- App’s certificate has proper key usages set
- App’s certificate contains the expected Cloud Foundry specific attributes (Org, Space, and Instance GUIDs)
- The JWT token was signed using the app’s public/private key pair
Once the plugin validates the provided JWT, it looks up the Vault policies to assign to the user. This can be done a number of ways.
In either case, the plugin is able to perform the lookup using its knowledge about the request:
- The app includes a role in its request. A Vault admin can then create a mapping of roles to policies. The roles can be scoped to Cloud Foundry Orgs, Spaces, or Instances
- A Vault admin creates a mapping of Cloudy Foundry Orgs, Spaces, and Instances to Vault policies
The plugin informs Vault that it approves or denies the token request. When approved, the plugin provides the Vault policies from the previous step and a sensible TTL, likely based on the certificate’s TTL.
Vault then creates an appropriately scoped token and returns it to the app. The app now uses the token to read and write secrets.

License

Licensed under the Apache License, Version 2.0: http://www.apache.org/licenses/LICENSE-2.0

OpenCage API Client

This repository is an OpenCage Geocoding API client for Node Typescript and JavaScript.

Continuous integration

Security

Source	Scores
FOSSA
Snyk

🎓 Tutorial

You can find a comprehensive tutorial for using this module on the OpenCage site.

🔧 Getting started

Sign up for a free-trial API Key.

NodeJS

First install the library with npm or yarn:

npm i --save opencage-api-client

or

yarn add opencage-api-client

or

pnpm add opencage-api-client

Starting in v2, dotenv is no longer bundled as a dependency. While we still recommend using .env files for configuration, you’ll need to set up dotenv yourself in your project.

Create a .env file with:

OPENCAGE_API_KEY=YOUR-OPENCAGE_DATA_API_KEY

Here are examples:

CommonJS

require('dotenv').config(); // or add `key` as an input parameter of the function geocode

const opencage = require('opencage-api-client');

opencage
  .geocode({ q: 'lyon' })
  .then((data) => {
    console.log(JSON.stringify(data));
  })
  .catch((error) => {
    console.log('error', error.message);
  });

ESM

import 'dotenv/config'; // or add `key` as an input parameter of the function geocode

import opencage from 'opencage-api-client';

opencage
  .geocode({ q: 'lyon' })
  .then((data) => {
    console.log(JSON.stringify(data));
  })
  .catch((error) => {
    console.log('error', error.message);
  });

Typescript

This example does not use dotenv and specify the API key as input parameter

import { geocode } from 'opencage-api-client';
import type { GeocodingRequest } from 'opencage-api-client';

async function geocode() {
  const input: GeocodingRequest = {
    q: '51.952659,7.632473',
    // The API Key value from process.env.OPENCAGE_API_KEY is overridden by the one provided below
    key: '6d0e711d72d74daeb2b0bfd2a5cdfdba', // https://opencagedata.com/api#testingkeys
    no_annotations: 1,
  };
  const result = await geocode(input);
  console.log(JSON.stringify(result,null,2));
}

Browser

The browser version is built using UMD notation. Modern browser can use the ESM version, here the example use the legacy JS notation.

The library is available with unkpg CDN : https://unpkg.com/opencage-api-client

1- include the library:

<!-- specific version -->
<script src="https://unpkg.com/opencage-api-client@1.1.0/dist/opencage-api.min.js"></script>

2- use it

opencage
  .geocode({ q: 'lyon', key: 'YOUR-API-KEY' })
  .then((data) => {
    console.log(JSON.stringify(data));
  })
  .catch((error) => {
    console.log('Error caught:', error.message);
  });

3- others Examples

You can find some examples in the examples folder.

✨ API

geocode(input, options?)

input: GeocodingRequest

Parameter	Type	Optional?	Description
q	String	mandatory	the query string to be geocoded: a place name, address or coordinates as lat,long
key	String	optional	the `key` can be omitted when using an `options.proxyURL` or when using a node runtime with a dedicated environment variable `OPENCAGE_API_KEY`
…	…	optional	Check the type definition and the API documentation for the other input parameters

options?: additional optional options

Parameter	Type	Optional?	Description
signal	AbortSignal	optional	The AbortSignal allow to cancel the request
proxyURL	String	optional	The proxy URL parameter (useful to hide your API key)

Error handling

API can return errors like invalid key, too many requests, daily quota exceeded, etc. Those errors are thrown as Javascript Error by the geocode function. The error object contains the same status object as the OpenCage API.

Assuming the catch statement uses error as variable name:

console.log('Error caught:', error.message);

will output for a 429:

Error caught: Too Many Requests

and

console.log(JSON.stringify(error, null, 2));

will output for a 429:

{
  "status": {
    "code": 429,
    "message": "Too Many Requests"
  }
}

Check the examples using the Test API key from OpenCage error handling examples

🔨 Build and test

Fork or clone this repository
cd into the repository folder
pnpm install to install all the required dependencies from npm
echo "OPENCAGE_API_KEY=YOUR-OPENCAGE_DATA_API_KEY" >.env to allow integration tests with your API key
lint and test coverage using pnpm run test:coverage
Build : pnpm run build
Test with the examples running ./scripts/run-examples.sh

🛣 Revision History

Check the CHANGELOG file.

🥂 Contributing

Anyone and everyone is welcome to contribute.

🐞 Issues

Find a bug or want to request a new feature? Please let me know by submitting an issue.

🗝 Licensing

Licensed under the MIT License

A copy of the license is available in the repository’s LICENSE file.

Author: 199opwmai497

MI BCI Analysis

MATLAB Toolbox

biosig

eeglab

Dataset

Resource

Instructions

Tested Environments

Authors

Contributions

android-rtlmarqueeview

Integration

Usage

License

GitLab Merge Request Concourse Resource

Source Configuration

Behavior

check: Check for new merge requests

in: Clone merge request source branch

out: Update a merge request’s merge status

Parameters

Example

E-REKRUTMEN

Myth:Auth

Project Notice

Requirements

Features

Installation

Manual Installation

Upgrading

Configuration

Overview

Routes

Views

Services

Helper Functions

Users

Toolbar

Restricting by Route

Customization

CodeIgniter 4 Development

What is CodeIgniter?

Documentation

Important Change with index.php

Repository Management

Contributing

Server Requirements

Running CodeIgniter Tests

E-REKRUTMEN

do_DogLcd

SlushFlicks

Architecture

Resource

DataManager

ErrorParser

ErrorMapper (Future Work)

Optimization

Cloudhus

Fully Automated Single Sign-On Feature

Sequence diagrams

Requirements

Setup process

Installing dependencies & building the target

Local development

Packaging and deployment

Testing

vault-plugin-auth-cloudfoundry

Background

CF

Vault

Design

Authentication Flow

License

OpenCage API Client

Continuous integration

Security

🎓 Tutorial

🔧 Getting started

NodeJS

`biosig`

`eeglab`

`check`: Check for new merge requests

`in`: Clone merge request source branch

`out`: Update a merge request’s merge status