Cloud Software Group, the parent of Citrix, urged Citrix Session Recording users to upgrade their software as soon as possible. The Cybersecurity and Infrastructure Security Agency also encouraged sers to review the bulletin and apply necessary upgrades.

Citrix Session Recording users warned of CVEs that allow hackers to gain control | Cybersecurity Dive

Ahead of President Joseph R. Biden's meeting with Vietnam General Secretary and President To Lam during the 79th Session of the United Nations General

U.S. And Vietnam Strengthen Cybersecurity Partnership | Mirage News

JEE Main <strong>session</strong> 2 2024: Once results are released, students can download it by accessing the direct link at JEE Main Nta.ac.in.

JEE Main Session 2 Final Result: NTA to release results tomorrow at Nta.ac.in - Education News | The Financial Express

JEE Main 2024 Result Live Updates: If a candidate has appeared in both <strong>sessions</strong>, the best of the candidate’s scores in JEE Main will be considered while preparing the final merit list. NTA will publish the marks official website – jeemain.nta.ac.in

JEE Main 2024 Result Live Updates: JEE results expected tonight at jeemain.nta.ac.in | Education News - The Indian Express

The Sensex and Nifty sustained their winning streak for the third day, but ended below their intraday highs amidst notable volatility. Sensex gained 90 points to close at 73,738, while Nifty rose by 32 points to settle at 22,368.

Market at Close | Sensex, Nifty gain for third straight session, Volatility Index slides 20%

The Standing Committee of the 14th National People&#x27;s Congress, China&#x27;s top legislature, started its ninth <strong>session</strong> Tuesday to review multiple draft laws and law revisions.The <strong>session</strong>&#x27;s agenda includes reviewing a draft academic degrees law, a draft tariff

China's top legislature starts standing committee session - CGTN

Students of KV Umroi Cantt engage in a newspaper reading <strong>session</strong>, on Monday. With the guidance of their librarian, Krishna Nand Singh, four students viz., Swastika, Prerna, Akashiya, and Aditya Choudhary emerged as the driving forces behind the <strong>session</strong>, demonstrating remarkable enthusiasm and ...

Students of KV Umroi Cantt engage in a newspaper reading session - The Shillong Times

The special live trading <strong>session</strong> on March 2 will divided into two phases for transition from the primary site to disaster recovery site.

NSE, BSE to conduct special live trading session tomorrow: Check timings, trade settlement details

Session

session

Understanding Authentication: A Guide to Cookie-Based and Session-Based Authentication

Online communication is undergoing a tidal shift as various groups and communities seek to relocate to more private and more secure messaging platforms. There are multiple reasons for this, such as simple personal preferences. But the main event triggering this shift was WhatsApp’s decision to alter its Terms of Service in a way that caused privacy concerns. WhatsApp geared to change its rules for data collection, claiming it was mostly for business-oriented features. The chat app does not plan to change the actual privacy characteristics of conversations and messaging. Despite their intentions and the real changes, a user exodus still happened, half-based on rumors and on the fear of an app that could snoop on data. The issue with WhatsApp caused a movement to boycott it and move to other chat apps. The trend may accelerate, as the user agreement changes came in force this February 8. The Facebook-owned app was also tainted by the impression of aggressive data harvesting. Even metadata can threaten security, especially for sensitive persons or information. The issue goes beyond personal privacy concerns. After the new WhatsApp rules came into force, the also united around the need to curb the collection of metadata and ensure privacy as a basic feature. However, the stance of EU governments allows for some forms of tracking, mostly for fraud and crime prevention, as well as for general traffic statistics. European Union Users still have a desire for stronger, more rigid protections than are being offered by EU regulation. Blockchain projects go a step further, centering on personal safety and anonymity, with no centralized entity to demand data. The rationalizations of WhatsApp are still ongoing, and it’s early to know what comes out of the situation. But the rise of subscriptions to alternative services point to a new niche — for neutral, confidential chat apps that are not aggressively attempting to collect data. We looked at three potential alternatives to WhatsApp, all arising from the blockchain space. Session and Oxen Blockchain The opportunity may be just ripe for blockchain-based, decentralized startups to take up the niche. The evidence is just rolling in — the Session private messenger is already counting over 50,000 active users, doubling just during the month of January, and influenced by the WhatsApp debacle. For now, the user count for Session is still in the growth stages, and far from the massive followings on legacy chat systems and social media. But the users joining are making up one of the biggest chat communities for a blockchain startup. is a next-generation private messenger with a fully decentralized infrastructure. The signup process does not require phone number verification, returning to the days of fully anonymous accounts. To route the messages and ensure privacy, the chat app uses the network, a blockchain and token-based project which emerged a few years ago as one of the promising startups dedicated to privacy. Session Oxen Session is straightforward about its goal to “send messages, not metadata”. Unlike big tech firms, Session has no plans to collect, use and analyze the datasets generated inevitably by user behavior. Instead, Session delegates its chats to a decentralized network, onion routing all chats anonymously through a distributed collection of incentivised nodes. Unlike many of its competitors, Session also doesn’t require a phone number to sign-up — instead generating a unique and secure Session ID for all users. But Session and Oxen rely on much more than end-to-end encryption. The Oxen protocol built a network of staked nodes that support the network, relying on distributed machines. To attract node operators, the OXEN digital asset serves as an incentive and reward for securing the network. OXEN uses the well-known CryptoNote technology, the very same used by Monero for veiled, confidential transactions. So beyond the chat encryption, all Oxen communications can remain undercover. Oxen is an open-source project with an invitation to builders, possibly becoming a vector for confidential connectivity. The OXEN asset, used as an incentive to trade, has already climbed to $0.85, following the positive trend of altcoins this year. Session has the advantage of being an early mover with a completed chat app. The idea of Oxen is to make its protocol freely available, so anyone can utilise the libraries and development tools that power Session. Oxen suggests anyone can build  — for example — a corporate chat similar to Slack, while using their best secure technology. Session took this a step further, by already onboarding users as an alternative to established apps. has also developed Lokinet, a well-developed standard for private browsing. Lokinet makes sure the chat data is routed through a system of nodes, where no one node knows the entire path of the message, thus raising its security and confidentiality. Oxen The advantage of Lokinet is that it can carry and route multiple protocols, including TCP, UDP, ICMP. Once Lokinet is fully implemented inSession, it will be able to offer both live calls and chat, but also high-traffic items like video. The network level on Lokinet goes beyond traditional onion routing, and is more capable of carrying demand for media-based communication. DeepOnion is one of the already well-established crypto projects dedicated to confidentiality. DeepOnion (ONION) is a well-known privacy coin with a real use case in both economic transactions and communication. Deep Onion The DeepOnion project combines The Onion Router (TOR) protocol at the native level, combining it with proof-of-work and encryption for sending coins anonymously. The initial goal of DeepOnion was to improve on the idea of Monero and similar coins, creating anonymous addresses and tools to send coins that cannot reveal a user’s identity, not even their pseudonyms. So far, DeepOnion does not have a dedicated chat app. But the project has a basic messaging function, which can send out encrypted messages alongside confidential transactions from its wallet. However, TOR-powered confidential messages are only a basic opportunity. DeepOnion is still not attempting to expand its products and introduce the chat app to replace usual channels of communication. Sylo goes a step further from the ONION crypto coin. The project built a wallet with the aim of creating “smart money”. But alongside the payment system, Sylo envisioned apps, storage solutions and communication. The Sylo network is geared to carry secure chats and calls. Sylo Sylo uses its proprietary system of nodes, incentivized with fees for each transaction similar to other blockchain networks. The decentralized group of nodes also provides computing resources, without known and centrally-controlled data centers and policies. This feature, inherent to blockchain networks, ensures that there are adequate, shared resources provided by a grass-roots organization. The presence of confidential blockchain networks and systems of nodes can be censorship-resistant, especially in the cases where participants provide their own node hardware, instead of relying on cloud services. Sylo uses the Signal protocol to sign its messages, ensuring state of the art end-to-end encryption. The open-source protocol also allows for chats and videos, as well as file transfers. As of 2021, the WhatsApp change of terms triggered multiple chat projects to start offering alternatives. This only adds to the movement to Signal or Telegram subscriptions. The new blockchain-based projects also stand as an alternative to Zoom, where end-to-end encryption is now a paid addition. Despite the initial appeal of WhatsApp for its encryption features, its metadata continued to expose users to potential data leaks or scams. A blockchain will not collect and store those sensitive data. But the app can build an accurate user profile, using simple but sensitive information - location, chat duration, the time of messaging, as well as connections to other easily identifiable users. Encryption and anonymity have always been a central interest and an almost perfect use case for blockchain applications. The exposures of chat systems that gather the data of billions of users will only accelerate the process of building alternative channels and networks.

Privacy Communities: Blockchain-Based Networks Rise After the Breakdown of Tech Giants

Hey there, fellow coder! Ever found yourself lost in the matrix of code, hours slipping by as you try to solve that one elusive bug or build a complex feature? We’ve all been there. But worry not, I’ve got some tried-and-tested strategies to help you stay on top of your game during those marathon coding sessions. 1. The Magic of Task Breakdown Before you dive into the sea of code, take a moment to break down your tasks into bite-sized pieces. It’s like having a roadmap for your journey. You can use fancy project management tools or just a good old to-do list. Trust me, it makes the journey less daunting. 2. The Power of the Pomodoro Ever heard of the Pomodoro Technique? It’s a simple yet effective method where you work for 25 minutes, then take a 5-minute break. After four of these cycles, you take a longer break, say 15–30 minutes. It’s like a mini-recharge for your brain, keeping you fresh and focused. 3. Hydrate and Nourish Remember, your brain needs fuel to function. Keep a water bottle handy and sip regularly. And don’t forget those healthy snacks to keep your energy levels up. Coding on an empty stomach? Not a great idea. 4. Exercise and Stretch Sitting for long hours can be a real pain, literally. Take short breaks to stretch or do some light exercise. It’s not just good for your body, but it also helps clear your mind. A win-win! 5. Tools and Shortcuts are Your Best Friends Spend some time getting to know your IDE and other tools. Those keyboard shortcuts can be real time-savers. And don’t forget about tools that can automate repetitive tasks. They’re like your personal coding assistants. 6. Mindfulness and Meditation A few minutes of mindfulness or meditation can do wonders for your stress levels and focus. It’s like hitting the refresh button on your brain. Give it a try! 7. Sleep is Not for the Weak Don’t underestimate the power of a good night’s sleep. It can boost your productivity, creativity, and problem-solving skills. So, before a long coding session, make sure you’re well-rested. 8. Say No to Distractions Turn off those pesky notifications, create a quiet workspace, and let others know you’re in the zone. There are even apps that can block distracting websites. It’s all about creating an environment where you can focus. 9. Document, Document, Document I know, when you’re in the zone, documentation seems like a chore. But trust me, it’s a lifesaver when you need to revisit or debug your code. So, don’t skip it. 10. Don’t Be Afraid to Ask for Help If you’re stuck on a problem, don’t hesitate to ask for help. There’s no shame in it. Use online communities like Stack Overflow, or ask a colleague or mentor. Remember, two heads are often better than one. So, there you have it. These are some strategies that have helped me during my coding marathons. Remember, everyone’s different, so feel free to experiment and find what works best for you. Happy coding! Also published . here

The Secret to Staying Productive During Marathon Coding Sessions 

Last week, we described the concept behind : you forward a request to the same upstream because there's context data associated with the session on that node. However, if necessary, you should replicate the data to other upstreams because this one might go down. In this post, we are going to illustrate it with a demo. sticky sessions Content Overview The overall design The heart of the application Configuring Spring Session with Hazelcast Configuring Spring Security Putting our design to the test Conclusion The overall design Design options are limitless. I'll keep myself to a familiar stack, the JVM. Also, as mentioned in the previous post, one should only implement sticky sessions with session replication. The final design consists of two components: an instance with sticky sessions configured and two JVM nodes running the same application with session replication. Apache APISIX The application uses the following: Dependency Description Spring Boot Eases the usage of Spring libraries Spring MVC Allows offering HTTP endpoints Thymeleaf View technology Spring Session Offers an abstraction over session replication Hazelcast (embedded) Implements session replication Spring Security Binds an identity to a user session The design looks like the following: and are two instances of the same app; I didn't want to overcrowd the diagram with redundant data. app1 app2 The heart of the application The heart of the application is a session-scoped bean that wraps a counter, which can only be incremented: @Component
@SessionScope
public class Counter implements Serializable {              //1

    private int value = 0;

    public int getValue() {
        return value;
    }

    public void incrementValue() {
        value++;
    }
} Necessary for Hazelcast serialization to work We can use this bean in the controller: @Controller
public class IndexController {

    private final Counter counter;

    public IndexController(Counter counter) {               //1
        this.counter = counter;
    }

    @GetMapping("/")
    public String index(Model model) {                      //2
        counter.incrementValue();
        model.addAttribute("counter", counter.getValue());
        return "index";
    }
} Inject the session-scoped bean in the singleton controller thanks to Spring's magic When we send a request to the root, increment the counter value and pass it to the model GET Finally, we display the bean's value on the Thymeleaf page: <!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" lang="en">
<body>
<div th:text="${counter}">3</div> Configuring Spring Session with Hazelcast Spring Session offers a filter that wraps the original to override the method. This method returns a specific implementation backed by the implementation configured with Spring Session, in our case, HttpServletRequest getSession() Session Hazelcast. We need only a few tweaks to configure Spring Session with Hazelcast. First, annotate the Spring Boot application class with the relevant annotation: @SpringBootApplication
@EnableHazelcastHttpSession
public class SessionApplication {
    ...
} Hazelcast requires a specific configuration as well. We can use XML, YAML, or code. Since it's a demo, I can choose whatever I want, so let's code it. Spring Boot requires either an Hazelcast object or a configuration object. The latter is enough: @Bean
public Config hazelcastConfig() {
  var config = new Config();
  var networkConfig = config.getNetworkConfig();
  networkConfig.setPort(0);                                                      //1
  networkConfig.getJoin().getAutoDetectionConfig().setEnabled(true);              //2
  var attributeConfig = new AttributeConfig()                                     //3
          .setName(HazelcastIndexedSessionRepository.PRINCIPAL_NAME_ATTRIBUTE)
          .setExtractorClassName(PrincipalNameExtractor.class.getName());
  config.getMapConfig(HazelcastIndexedSessionRepository.DEFAULT_SESSION_MAP_NAME) //3
          .addAttributeConfig(attributeConfig)
          .addIndexConfig(new IndexConfig(
            IndexType.HASH,
            HazelcastIndexedSessionRepository.PRINCIPAL_NAME_ATTRIBUTE
  ));
  var serializerConfig = new SerializerConfig();
  serializerConfig.setImplementation(new HazelcastSessionSerializer())            //3
                  .setTypeClass(MapSession.class);
  config.getSerializationConfig().addSerializerConfig(serializerConfig);
  return config;
} Choose a random port to avoid port conflict Allow Hazelcast to search for other instances and automagically form a cluster. It's going to be necessary when deployed as per our design Copy-pasted from the Spring Session documentation Configuring Spring Security Most Spring Session examples somehow use Spring Security, and though it's not strictly necessary, it makes the design easier. I want to explain why first. One can think about sessions as a gigantic hash table. In regular applications, the key is the cookie value, the value, and another hash table of session data. However, the is specific to the node. The app will give a different if one uses another node. Since the key is different, there's no way to access the session data, even if the session data is shared across nodes. To prevent this loss, we need to come up with a different key. Spring Security allows using a principal (or the login name) as the session data key. JSESSIONID JSESSIONID JSESSIONID Here's how I set up a basic Spring Security configuration: @Bean
public SecurityFilterChain securityFilterChain(UserDetailsService service, HttpSecurity http) throws Exception {
  return http.userDetailsService(service)                                    //1
             .authorizeHttpRequests(authorize -> authorize.requestMatchers(
                 PathRequest.toStaticResources().atCommonLocations())        //2
                            .permitAll()                                     //2
                            .anyRequest().authenticated()                    //3
             ).formLogin(form -> form.permitAll()
                                     .defaultSuccessUrl("/")                 //4
             ).build();
} The default in-memory user details service doesn't allow custom user details classes. I had to provide my own. Allow everybody to access static resources at "common" locations All other requests must be authenticated Allow everybody to access the authentication form Redirect to the root if successful, which maps the above controller Putting our design to the test Besides the counter, I want to display two additional pieces of data: the hostname and the logged-in user. For the hostname, I add the following method to the controller: @ModelAttribute("hostname")
private String hostname() throws UnknownHostException {
    return InetAddress.getLocalHost().getHostName();
} Displaying the logged-in user requires an additional dependency: <dependency>
    <groupId>org.thymeleaf.extras</groupId>
    <artifactId>thymeleaf-extras-springsecurity6</artifactId>
</dependency> On the page, it's straightforward: <!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org"
      xmlns:sec="http://www.thymeleaf.org/extras/spring-security">  
<body>
<td sec:authentication="principal.label">Me</td>                     Add the namespace. It's not necessary but may help the IDE to help you sec Require the underlying implementation to have a method UserDetail getLabel() Last but not least, we need to configure Apache APISIX with sticky sessions, as we saw last week: routes:
  - uri: /*
    upstream:
      nodes:
        "webapp1:8080": 1
        "webapp2:8080": 1
      type: chash
      hash_on: cookie
      key: cookie_JSESSIONID
#END Here's the design implemented on Docker Compose: services:
  apisix:
    image: apache/apisix:3.3.0-debian
    volumes:
      - ./apisix/config.yml:/usr/local/apisix/conf/config.yaml:ro
      - ./apisix/apisix.yml:/usr/local/apisix/conf/apisix.yaml:ro    #1
    ports:
      - "9080:9080"                                                  #2
    depends_on:
      - webapp1
      - webapp2
  webapp1:
    build: ./webapp
    hostname: webapp1                                                #3
  webapp2:
    build: ./webapp
    hostname: webapp2                                                #3 Use the previous configuration file Only expose the API Gateway to the outside world Set the hostname to display it on the page We can log in using one of the two hard-coded accounts. I'm using , with password and label . Notice that Apache APISIX sets me on a node and keeps using the same if I refresh. john john John Doe We can try to log in with the other account ( / ) from a private window and check the counter starts from 0. jane jane Now comes the fun part. Let's stop the node which should be hosting the session data, here and refresh the page: webapp2 docker compose stop webapp2 We can see exciting things in the logs. Apache APISIX can no longer find the , so it forwards the request to the other upstream that it knows, . webapp2 webapp1 The request is still authenticated; it goes through Spring Security The framework gets the principal out of the request It queries Spring Session And gets the correct counter value that Hazelcast replicated from the other node The only side-effect is an increased latency because of Apache APISIX timeout. It's 5 seconds by default, but you can configure it to a lower value if needed. When we start again, everything works as expected again. webapp2 Conclusion In this post, I described a possible setup for sticky sessions with Apache APISIX and replication involving the Spring ecosystem and Hazelcast. Many other options are available depending on your stack and framework of choices. The complete source code for this post can be found on . GitHub To go further: Spring Session and Spring Security with Hazelcast Spring Session Hazelcast Originally published at on July 2nd, 2023 A Java Geek

Demo: Sticky Sessions with Apache APISIX for Improved Load Balancing

Sticky sessions, also known as session affinity, is a mechanism by which a routing component, that acts as a facade, always routes a request to the same underlying upstream node. In this post, I'll describe the reason behind sticky sessions, available alternatives, and how to implement them via Apache APISIX. Why sticky sessions? Sticky sessions became popular when we stored the state on the upstream node, not the database. I'll use the example of a simplified e-commerce shop to explain further. The basic foundations of a small e-commerce site can consist of a web application and a database. If the business is successful, it will grow, and you'll need to scale this architecture at some point. Once you cannot scale vertically (bigger machines), you must scale horizontally (more nodes). With additional apps node, you'll also need a load balancer mechanism in front of the web app nodes to distribute the load among them. Going to the database every time is an expensive operation. It's ok for data that is accessed infrequently. However, we want to display the cart's content for every request. A couple of alternatives are available to speed things up. If we assume that the web app uses Server-Side Rendering, the classical solution is to keep cart-related data in memory on the web app node. However, if we store user X's cart on node 1, we need to ensure that we forward every request of user X to the same node. Otherwise, they will feel as if they lost their cart's content. Sticky sessions, or session affinity, is the mechanism that consistently routes the same user to the same node. Limitation of sticky sessions Before going further, I must explain a significant limitation of sticky sessions. If the webapp node that stores the data goes down for any reason, the data are irremediably lost. For the e-commerce scenario above, it means users will lose their cart occasionally, which is unacceptable from a business point-of-view. For this reason, sticky sessions must go hand-in-hand with : data stored on a node must be copied and kept in synch with all other nodes. session replication While session replication exists in all tech stacks, there's no related specification. I'm familiar with the JVM, so here are a couple of options: Tomcat offers out-of-the-box session replication offers a clustered in-memory solution that you can integrate at different levels Hazelcast is an abstraction layer upon specific solutions Spring Session When data is replicated on all nodes (or a remote cluster), you may think you no longer need sticky sessions. It's true if one accounts only for availability and not for performance. It's about data locality: fetching data on the current node than from somewhere else via the network is faster. Sticky sessions on Apache APISIX Sticky sessions are a must-have for any Load Balancer, Reverse Proxy, and worth their salt. However, I must admit that Apache APISIX's documentation needs an easy entry point into the subject. API Gateway binds a to an . An upstream consists of one or more nodes. When a request matches the route, Apache APISIX must choose among all available nodes to forward the request to. By default, the algorithm is weighted round-robin. Round-robin uses one node after the other, and after the last one, get back to the first one. With a weighted round-robin, the weight affects how many requests Apache APISIX forwards to a node before it switches to the next one. Apache APISIX route upstream However, other algorithms are available: Consistent hashing Exponentially Weighted Moving Average Chart Least connection A custom-made one Consistent hashing allows forwarding to the same node depending on some value: an NGINX variable, an header, a cookie, etc. HTTP Remember that HTTP is a stateless protocol, so application servers set a cookie on the first response to track the user across HTTP requests. It's what we call a "session". We need to know the underlying session cookie name. Different application servers hand out different cookies: for JVM-based servers JSESSIONID for PHP PHPSESSID for ASPSESSIONID ASP.Net etc. I shall use a regular Tomcat, so the session cookie is . Henceforth, the Apache APISIX documentation for two nodes is the following: JSESSIONID routes:
  - uri: /*
    upstream:
      nodes:
        "tomcat1:8080": 1            #1
        "tomcat2:8080": 1            #1
      type: chash                    #2
      hash_on: cookie                #3
      key: cookie_JSESSIONID         #4 Define the upstream nodes Choose the consistent hashing algorithm Hash on cookie Define which cookie to hash on Conclusion In this post, we detailed sticky sessions, that you should always use session replication with sticky sessions, and how to implement sticky sessions on Apache APISIX. To go further: Load Balancing Upstream configuration The illusion of statelessness Originally published at on June 25th, 2023 A Java Geek

Implementing Sticky sessions via Apache APISIX

The Noonification: Efficient Session Handling Using the Repository Pattern in FastAPI (6/10/2023)

I wrote an about five months ago about adapting the repository pattern with FastAPI, and I got a whole lot of reads (thank you). I have come to write about an efficient way to handle session handling, still using the repository pattern. article Before I jump right into it, I noticed that on production, I get either of the following errors whenever my APIs are trying to make a transaction that involves reading or writing to the database: sqlalchemy.exc.PendingRollbackError sqlalchemy.exc.InvalidRequestError sqlalchemy.exc.PendingRollbackError This error indicates that there is an uncommitted transaction in progress that needs to be rolled back before proceeding with any other database operations. The most common cause of this error is an unhandled exception occurring during a database transaction, which prevents the transaction from being committed or rolled back properly. sqlalchemy.exc.InvalidRequestError This error indicates that an operation or request that you made to the database is invalid or not supported. There can be various causes for this error, including: Incorrect usage of SQLAlchemy API, such as calling a method or accessing an attribute that doesn't exist or is not applicable in the given context. Incorrect SQL syntax or query structure. Missing or incorrect mapping between Python objects and database tables/columns. I am certain that you have thoughts about how these errors can be resolved, however, I would like to state that even though I identified what the problem was and made a fix- the problem persists. If you are curious as to how I troubleshoot and resolve them, you can consider following the following steps: sqlalchemy.exc.PendingRollbackError: Review your code for any unhandled exceptions that might prevent transactions from being committed or rolled back properly. Ensure that you are properly handling exceptions and either committing or rolling back the transaction as needed. Check for any long-running or nested transactions that might lead to pending rollbacks. Make sure that all transactions are committed or rolled back in a timely manner. Review your code for any cases where you might be starting a new transaction before properly handling the previous transaction. sqlalchemy.exc.InvalidRequestError: Review the specific error message provided with the exception to identify the cause of the invalid request. It might give you hints about what part of your code or SQL statement is causing the issue. Check your SQLAlchemy code for any incorrect method calls, attribute accesses, or incorrect usage of the API. Review your SQL statements to ensure they have the correct syntax and structure. Verify that your database schema and SQLAlchemy mappings are in sync. Ensure that all required tables and columns exist and that your Python objects are properly mapped to the corresponding database entities. Let’s get right into how I worked on a permanent solution that has proven to work for me. I shall proceed to use a project that I worked on when I was demonstrating how to use repository patterns. We had a module where we stored our orm base session mixin with the following codes: # SQLAlchemy Imports
from sqlalchemy.orm import Session

# Own Imports
from config.database import SessionLocal
from core.settings import ledger_settings


class ORMSessionMixin:
    """Base orm session mixin for interacting with the database."""

    def __init__(self):
        """
        Get the next database session from the database pool.
        """
        self.orm: Session = self.get_db().__next__()

    def get_db(self):
        """
        This method creates a database session,
        yields it, rollback the transaction if there's an exception 
        and then finally closes the session.

        Yields:
            db: scoped database session
        """
        db = SessionLocal()
        try:
            yield db
        except Exception:
            db.rollback()
        finally:
            db.close() The problem with this solution was that if an exception occurs in the process of a transaction (this could be anything: creating a user, funding your wallet, etc.)- the exceptions are not properly handled, and the database session in transit does not get rollback. After three months of debugging and patching and lots of research, I finally was able to build an efficient way of handling sessions. # SQLAlchemy Imports
import sqlalchemy
from sqlalchemy.orm import Session

# Own Imports
from config.database.connection import SessionLocal


class DatabaseSessionMixin:
    """Database session mixin."""

    def __enter__(self) -> Session:
        self.db = SessionLocal()
        return self.db

    def __exit__(self, exc_type, exc_val, exc_tb):
        try:
            if exc_type is not None:
                self.db.rollback()
        except sqlalchemy.exc.SQLAlchemyError:
            pass
        finally:
            self.db.close()
            SessionLocal.remove()


def use_database_session():
    return DatabaseSessionMixin() In this code: is a context manager class that handles the session and ensures that it is properly closed and rolled back in case of an error. DatabaseSession method initializes the session and returns it. __enter__ method checks for exceptions and rolls back the session if an exception occurred. It then closes the session and removes it from the scoped session. __exit__ is a utility function that can be used as a decorator or context manager to simplify session usage. use_database_session Here's an example of how you can use the use_database_session utility function: with use_database_session() as db:
    # perform logic that uses the session
    # ...

# After exiting the context, the session will be automatically closed and removed from the scoped session. The above approach provides a cleaner and more efficient way to handle sessions and ensures that they are properly rolled back or closed in case of an error. Let’s proceed to how you implement the repository pattern while using the database session in the ORM. # SQLAlchemy Imports
import sqlalchemy
from sqlalchemy.orm import Session


class BaseRepository:
    def __init__(self, session: Session):
        self.db = session


class UserRepository(BaseRepository):
    """Operations to interact with the `users` table in the database."""
    
    def get(self, user_id: int) -> User:
        """This method gets a user from the database."""

        user = (
            self.db.query(User)
            .filter(User.id == user_id)
            .first()
        )
        return user

    def create(self, name: str, email: str, password: str) -> User:
        """This method creates a user."""

        user = User(name=name, email=email, password=password)

        self.db.add(user)
        self.db.commit()
        self.db.refresh(user)

        return user

    def update_user(self, user_id: int, updated_data: dict):
        """This method updates a user."""

        user = self.get(user_id)
        if user:
            for key, value in updated_data.items():
                setattr(user, key, value)
            self.db.commit()
            return user
        return None

    def delete_user(self, user_id):
        """This method deletes a user."""

        user = self.get_user(user_id)
        if user:
            self.db.delete(user)
            self.db.commit()
            return True
        return False Next would be to integrate the above repository into the service layer of your application. Suppose you have a service function that creates users account; here’s how you’d do it using our new method: # Apps Imports
from apps.users.models import User
from apps.users.repo import UserRepository
from apps.users.schemas.auth import UserCreate

# Config Imports
from config.security.hashers import password
from config.database.session_mixin import use_database_session


async def create_user(user: UserCreate) -> User:
    """
    This function creates a new user in the database.

    :param user: schemas.UserCreate
    :type user: schemas.UserCreate

    :return: The user object
    """

    with use_database_session() as db:
        users_repo = UserRepository(db)
        user = users_repo.create(
            user.name, 
            user.email, 
            password.hash(user.password)
        )
        return user The above pattern will allow you to encapsulate database operations within repository classes while leveraging the inherited database session. It also provides a clean separation between your ORM models and the repository logic. Conclusion In conclusion, efficient handling of sessions is important when building backend systems. The errors like and that occur during database transactions can lead to data inconsistencies and application failures if not handled properly. sqlalchemy.exc.PendingRollbackError sqlalchemy.exc.InvalidRequestError Identifying and resolving these errors is important for maintaining the integrity and reliability of the system. To address the issues related to session handling, it is essential to implement robust strategies. One approach is to use context managers, such as the we demonstrated in the article. DatabaseSessionMixin This context manager ensures that sessions are properly opened, closed, and rolled back in case of exceptions. By encapsulating the session logic within the context manager, you can streamline session management and improve error handling. Additionally, integrating the repository pattern into the service layer of the application can further enhance the efficiency of session handling. By separating the database operations into repository classes and leveraging the inherited session from the context manager, you can achieve cleaner code organization and maintain a clear separation between ORM models and repository logic. Overall, efficient session handling is crucial for maintaining data consistency, preventing errors, and ensuring the stability of backend systems. By following best practices, such as using context managers and adopting the repository pattern, developers can build robust and reliable systems that effectively manage sessions and handle errors during database transactions. I am to writing gigs and actively searching for contract roles that involve building with Python (Django, FastAPI, etc.). open

Efficient Session Handling Using the Repository Pattern in FastAPI

FastAPI-তে রিপোজিটরি প্যাটার্ন ব্যবহার করে দক্ষ সেশন হ্যান্ডলিং

Effiziente Sitzungsverwaltung mithilfe des Repository-Musters in FastAPI

Manejo eficiente de sesiones usando el patrón de repositorio en FastAPI

Gestion efficace des sessions à l'aide du modèle de référentiel dans FastAPI

FastAPI में रिपॉजिटरी पैटर्न का उपयोग करके कुशल सत्र संचालन

FastAPI のリポジトリ パターンを使用した効率的なセッション処理

FastAPI의 리포지토리 패턴을 사용한 효율적인 세션 처리

Tratamento de sessão eficiente usando o padrão de repositório no FastAPI

FastAPI'de Depo Desenini Kullanarak Verimli Oturum İşleme

Xử lý phiên hiệu quả bằng cách sử dụng mẫu kho lưu trữ trong FastAPI

使用 FastAPI 中的存储库模式进行高效会话处理

The objective of this article is to evaluate the security posture of the WEB session management. Distinguish the common attack patterns and vulnerable conditions, provide countermeasures to act. Applicable Laws, Regulations, Standards & Guidance The following cybersecurity laws, regulations, industry standards, and guidance are applied to this assessment. ✅[NIST SP 800–115] Technical Guide to Information Security Testing and Assessment. ✅[RFC-6265] HTTP State Management Mechanism. ✅[RFC-4086] Randomness Requirements for Security. ✅[ISO/IEC 24792:2010] Multicast Session Management Protocol (MSMP). ✅[OWASP-ASVV] Application Security Verification Standard 4.0.3. The Open Systems Interconnection (OSI) model: The standard OSI model is divided into seven different types of layers as like shown in Figure 1, and further these layers can be grouped into two top level layers such as host layers and media layers. Each layer’s host a vast multifarious protocol suite, the predominant one is the TCP/IP suite. A set of protocols are used to form an end to end communication on the internet using the underlying principles of OSI model. 2.1 A cross layer triad: A cross-layer functions work with multiple layers and functions to handle their services. 2.1.1 Transport Layer: TCP helps to transport the data reliably from a source to the destination point via an end-to-end service while pertaining a QoS via connection-oriented service. Whereas UDP transport the data via connectionless service. 2.1.2 Session Layer: In client-server model, distributing an application service to the client is the common principle. The protocols X.225 (ISO 8327), X.235 (ISO 9548–1) are responsible to controls ports, establish, maintain, data transfer, steaming, terminate sessions between the client and server nodes. The session expiration is handled in two ways, manual termination through logout, and automatic termination through session idle, timeout, and renewal timeout. This layer offers data streaming in three different ways, simplex, half-duplex, and full-duplex modes. 2.1.3 Presentation Layer and Application Layer: The presentation layer defines the format, and encryption factors, for the provided data. Application layer act as an interactive layer correspondence between external devices and human user. 3. A WEB Application Session Management: 3.1 Session management: The data flow between the two endpoints are synchronized timely, which maintain the session entities. The popular tool provided by session layer is Application programming Interface (APIs), which is used by NetBIOS, TCP/IP, and RPC. The following services are offered by the session layer. The hierarchy of the session management is depicted in Figure 2. 3.1.1 Session Authentication, Authorization, Access policies (AAA): Authentication and Authorization: In the client-server model, when a client sends an HTTP request packet (HTTP header, message) via a component URL parameters, an application server acknowledges and provide a response to the client. When multiple requests are received from the same client, session management maintain session information’s associated to the same user once they are authenticated. This derivative observes and serve pre- and post-authentication scenarios. The objective of such request is to obtain the requisite resources. In the modern application framework, an authenticated session generates a session identifier is called session ID or also known as token which is used for a user identification. Each application interlinks the pre-authentication, post-authentication, session functions with appropriate authorization controls enforced by the owner. Due to less stringent measures on these three functions, which makes any application vulnerable to attacks. Types of Cookies The sessions are stored in cookies. The cookies are classified into two groups-session and persistent cookies. In session cookie an expiration date field is not defined and stored in the memory not on disk, whereas in persistent cookies it’s defined and stored on the disk. 3.1.2 Session Restoration: Most of the distributed applications are up for longer duration, App session failure is inevitable during the operation. When it occurs, session layer utilizes the session restoration function to capture the snapshot of the live events in timeframe series and restore a session upon the failure of a particular timestamp. 4. Session Analysis and Threat Identification: In session analysis, to identify, and analyse the received “A.pcapng” file from the Hexagon corporation and exhibit on how it’s exposed on the WEB. 4.1 Assessment Tools: The following commercial and open-source tools has been utilized. 1. Windows 10, 64-bit Microsoft Operating system (OS). 2. Wireshark Packet analyser. 4.2 Wireshark case study: Globally renowned open-source tool offers an extensive functionality such as traffic analysis, packet capturing, sniffing, decrypting traffic, statistics, etc., 4.2.1 IPV4 and TCP Conversation Filter: To apply the filer, using the given command. In total, there are 18 packets. 4.2.2 TCP and HTTP Stream packets: To apply the stream packet filter. 4.2.3 Checksum and HTTP sequence info: To use “expert information”, to extract the notable issues to justify the root cause. Checksum Error: In an invalid checksum, packets were reported and deemed to be invalid. The packet was corrupted during the transfer. Sequence Error: We identified a suspicious activity; a set of packet sequence wasn’t in a continuous order and highly likely packet retransmission was performed. A URL passing the username and password was found in cleartext format. Packet analysis: 4.2.4 HTTP Analysis: 4.3 Summary of Session investigation and attack methodologies: Microsoft IIS server V.10 was used. ✓ ASP.NET V.4.0.30319 was used. ✓ HTTP response splitting, XSS, DoS, privilege escalation, HTTP request hijacking, RCE based CVEs are presented on the Microsoft ISS V10. ✓ Cache-Control: max-age=0 was used to revalidate each cache entry, and return code was 302. The server should never cope the same cache. Refer to Figure 6. Cache control data. ✓ Cache-Control: private defines, it can be cached locally on the device. ✓ Open TCP Port (80), Entropy in/out. ✓ Session open date: 2021–12–22 11:14:42 UTC, Session end: 2021–12–22 11:14:53 UTC. ✓ Total number of detected files 4. ✓ Incorrect Timestamp in the HTTP GET/POST headers. ✓ Inadequate session ID length. ✓ Secure attribute https was not implemented. ✓ Lack of encryption standards (No encryption, no password masking, HASH, salts). ✓ Used predictable dictionary words as username and password. ✓ Different Attack techniques: The following attack techniques can be applied on the WEB sessions files. Session ID and Attacks: The stored session ID is prone to numerous attacks. The attacker can perform brute force, session hijack, session play, and privilege escalations to harm the victim. The objective is to obtain the privileges and impersonate as a legitimate user. Majority of the attacks happens after the post authentication, such as hijacking an authenticated user session to steal IDs, passwords, taking advantage of low integrity check features, executable commands, session fixation assist attackers to steal valid IDs, improperly defined access policies, less stringent verification leads to cross-site request forgery (CSRF) attack. 4.4 Recommendations/Mitigations: The following TTPs can be applied to the WEB sessions management. To implement a secure session ID for each individual session. ✓ Recommend configuring minimum 16 bytes length. ✓ To configure CSPRNG with 8 bytes entropy value to prevent statistical based guessing attacks. ✓ Session content should never hold personally identifiable information, excluding necessities. ✓ To use the latest framework and IIS server to prevent CVEs logging on. ✓ To protect integrity, use secure cryptographic protocols HTTPS/TLS1.2/TLS1.3 versions on the WEB. ✓ To prevent scripts accessing cookies. ✓ To prevent XSS attack from intruders, configure WEB worker to store in the web browser. ✓ To perform verification and validation of the session ID. ✓ Manual and automatic session expiration such as idle, absolute, renewal timeout values should be configured. ✓ To enforce enhanced countermeasures, use JavaScript to set initial timeout, valid session forced expiration, and disable cross tab cookie sharing. ✓ To increaser the scrutiny on session attempt principles. ✓ Restrict users to WEB directory traversal, object queries, sessions tokens, parameterize queries through SQL injection attacks. ✓ Integrate SAST/DAST testing throughout the CI/CD pipeline activities. Always use latest’s application security frameworks ✓ Develop, monitor, and use encoding techniques on web pages. Refer to XSS, SQL,CSRF cheat sheets. ✓ Enforce input validation on server side because incoming data should be treated as untrusted. ✓ Enforce automated controls, centralized management, analytics, strong authentication, authorization, MFA, SSO policies. ✓ To enable a SIEM controls on the server for security events and compliance. ✓ 5 Conclusion: In this assessment, we analysed, and explored the different types of attacks, techniques, and provided required countermeasures to enhance. Also published . here

Reviewing the Security Posture of Web Session Management With Wireshark

I was recently working on a side project in my free time when I ran into a really weird issue with Supabase and, specifically the client library. @nuxtjs/supabase What I was attempting to do was to make an API call to get data to populate a profile page as soon as the user loaded the page. We had set up the backend API to require a basic auth token. The code looked something like this: <script setup>
const client = useSupabaseAuthClient();

const session = await client.auth.getSession();

await useFetch(`${API_URL}/profile/:user_id`, {
  headers: {
    Authorization: `Bearer ${session.data.session.access_token}`,
  },
  onResponse({ request, response, options }) {
    console.log(response);
    //do other stuff
  },
}); What went wrong? Rather than console logging out a 200 we got an error before we could even make a request. TypeError: Cannot read properties of null (reading 'access_token') Well that’s weird why would the not have a session? client.auth.getSession() What was weirder was just console.logging it out would also give us the same error const client = useSupabaseAuthClient();
const session = await client.auth.getSession();
console.log(session.data.session.access_token); What if we tried this? const client = useSupabaseAuthClient();
const session = await client.auth.getSession();
console.log(session.data.session?.access_token); Funny enough this actually worked. It would log out the correct access token. It was at this moment I realized what was wrong. But I wanted to confirm if my thinking was correct with one last experiment. I decided to wrap the entire fetch call with a try/catch block try {
  const { data: fetchedProfileData, refresh } = await useFetch(
    `${API_URL}/profile/:user_id`,
    {
      headers: {
        Authorization: `Bearer ${
          (
            await client.auth.getSession()
          ).data.session.access_token
        }`,
      },
      onResponse({ request, response, options }) {
        console.log(response);
      },
    }
  );
} catch (e) {
  console.error(e);
} It worked but didn’t? So if you know the answer to this problem, it shouldn’t surprise you that the page loaded fine and the data was logged out properly. But at the same time there was also a second console.log message. TypeError: Cannot read properties of null (reading 'access_token')
...
//Access token logged here: How could we be getting an error that the session is null but then log the access token at the same time? Answer: Vue lifecycle methods So I want to say the core problem was that for whatever reason, a large part of is not setup until after things are rendered in the lifecycle. And if you don’t explicitly state a lifecycle method our API call would run before the initial render. Whether that’s intentional or not I’m not exactly sure. The API call works with a try/catch block because on that initial load the API call errors out but as we continue our way along the Vue lifecycle the API call gets called again and this time around is set properly and we can go on our merry way. client.auth.getSession() client.auth.getSession() You can use the try/catch block but the better and cleaner way to do things is to use a lifecycle hook. In this instance or works well. onMounted onBeforeMount Docs here onMounted(async () => {
  const session = await client.auth.getSession();
  await useFetch(`${API_URL}/profile/:user_id`, {
    headers: {
      Authorization: `Bearer ${session.data.session.access_token}`,
    },
    onResponse({ request, response, options }) {
      console.log(response);
      //do other stuff
    },
  });
}); Voila, now the errors are gone and we have our data. With this you can also trigger the error if we use the hook because we’re forcing our fetch to be called before the component instance is even rendered on the server onServerPrefetch //This will error
onServerPrefetch(async () => {
  const session = await client.auth.getSession();
  const x = await useFetch(`${API_URL}/profile/:user_id`, {
    headers: {
      Authorization: `Bearer ${session.data.session.access_token}`,
    },
    onResponse({ request, response, options }) {
      console.log(response);
      //do other stuff
    },
  });
}); Conclusion I hope this helps anyone else who ran into this issue with Supabase and Nuxt and hopefully someone reads this and can give a better explanation or confirm my suspicions in the comments since I’m mostly a backend developer and I only touch frontend code in my free time.

Having Trouble Accessing Your Session and Access Token Using Supabase, Nuxt and Vue3? Try This!

The process of brainstorming can be divided into three steps: preparation for brainstorming, brainstorming session and the selection of results. To prepare for brainstorming, it is necessary to gather a team, acquaint all the participants with the rules of brainstorming, and also prepare questions, which will help structure the brainstorming process. You need to know the expertise of people that you need for facilitating/conducting the brainstorming session, participating in it and filtering the results. Your goal is to use the experience and knowledge of all the teams' participants and optimise the team's potential. It is useful to invite experts from different fields to participate in brainstorming. A multifaceted team might promote a variety of new ideas. Before beginning to brainstorm, you must also nominate a facilitator and get to know the team. During brainstorming, the main task is to generate as many different ideas as possible and to think outside the box. The Analogy, Powers of Ten and Inversion methods can help you arrive at unconventional and innovative solutions. In order to review ideas after brainstorming, use methods like voting, the 4 Categories method and the Bingo method. Brainstorming Rules We block out a chunk of time for brainstorming, during the course of which we will generate ideas but not evaluate them. There are several requirements which are important for the success of brainstorming based on UX industry recommendations: The more ideas that are suggested, the greater the chance of finding "diamonds" among them, which will serve as the basis for our future prototypes. Quantity gives birth to quality. At this early stage, the task of the participants is to be open to even the most radical ideas in order to stir up their creative potential. Criticism and personal opinions belong in the following stage, where we will analyse and select ideas. Now, it is important to maximise the development of all suggested ideas though collective strength. Do not "fall in love" with your idea and do not allow your personal preferences and prejudices to disturb the process. Do not evaluate or critique at this stage. It is possible that these unconventional ideas may in some form lead you to an unexplored solution to the problem. Do not throw away "crazy" ideas. . Add to and develop ideas together. Unify ideas. It is possible that unifying two ideas could result in a third which is even more interesting. Unify and improve your ideas and other people's ideas Give every participant the chance to speak. Do not interrupt. When generating ideas, always think about your goal, the context and the users for whom you are creating this solution. The user is not you. That person had different experiences, preferences and goals. Do not stray too far from the main problem. The idea will not need as much special explanation if you give it a name, such as a headline in a newspaper. Metaphors often help (for example, "Pocket Bank"). Give your ideas names! Sometimes it is much easier to communicate an idea with a sketch, a scheme or a diagram. Make sketches. How Might We. . . ? Why use it? Short questions like How might we…." help to ignite the process or generating ideas. These questions must flow from the design process (requirements for a solution) and the formulation of the problem questions must be of a general character in order to remain open to imagination while remaining within the framework of the given problem and focusing on the user. How to use it? Begin with your formulated problem. Write it on a separate page of the flip chart. Divide this larger problem into a number of smaller ones. Look at how aspects of your problem can be connected to the question " How might we…?" Question. Explain to the team that we now have to transition from analysis of information to the realm of possible solutions. Distribute the stickers and markers. It is best to use the colour of stickers that is different than the one you used for insights. This will help to avoid confusion. Ask the members of the team to generate possible solutions in the format of an answer to the question "How might we…?" Team Warm-Ups Before transitioning directly to brainstorming, you might do several exercises which will help the participants warm-up and enliven the thinking process, raise team spirit and morale, have some fun and improve current work on the brainstorming. Here are several examples of exercises: In the beginning, everyone stands either in a line or a circle and thinks of a topic. The topic can be anything for example, "Major Spending Patterns", “Why do I use the bank” or “What does money mean for me?" Every participant must name something concerning the given topic. If the participant does not name anything, he or she is removed from the game. The exercise should proceed without pauses at a brisk tempo. Stand in a circle and imagine that you are throwing an imaginary hall to one another. Look at the person who you have decided to throw the ball to, and then with some kind of noise, signal that the ball is flying through the air. Then, whoever catches the "ball" should repeat your sound and, with a new sound, throw it to another participant. Try to pass the ball as fast as possible. All participants should spread out in a room and wait. Then, one of the participants gives a command that begins with the words "Let's pretend that" and can end the sentence in any manner. Upon hearing the command the participants answer in chorus "yes, let's" and carry out the command. For example: "Let's pretend that we stand in line and do not know how to occupy ourselves", "Let's pretend we do not know what gravity is", etc. After these phrases are spoken, the participants must act them out. The leader suggests a topic. For example, "Let's organise a holiday!" Another participant must take up this topic, beginning with the words "yes, and..." (for example "yes and order pizza"). Continue in this manner until all members of the team have taken part. For a sufficient warm up, go through two to three topics. Brainstorming Sessions What do you need? You will need stickers and markers for every participant, several sheets of flip chart paper, a free wall or whiteboard for writing, and a tape for taping the flip chart paper to the wall. Give every participant stickers and markers. The participants will write their ideas on stickers, so it is important to write or draw only one idea per sticker to avoid confusion during the result collection process. Where to make it? Find a special room or workspace that is conducive to the generation of ideas. Sit in order to hear and see each other well. It is best to sit in a circle as it helps create a sense of flat organisation, as well as have evervone see and hear each other equally well. Write down the topic of the brainstorming session. Questions like "How might we. ..?" are great departure points for the discussion. How much time it takes? It is best to establish a time limit beforehand. This will help focus the working process. Brainstorming requires very intense mental work and therefore, should be limited to 15-30 minutes at any time. List of questions. Prepare 3-5 ("How might we ... ?") questions. Write each question on a separate sheet of flip chart paper or divide the whiteboard into sections so that every question has its own column. Roles. Usually, during brainstorming, there are idea generators (the team participants) and a facilitator. Format. There are many ways to conduct a brainstorming session. Here are two of the most widespread tactics: Appoint a facilitator who will write ideas on stickers and arrange them on the whiteboard, flip chart paper or a free wall. It is important that the facilitator writes down all ideas, even if they do not like them. Every participant individually writes his or her own ideas on a sticker as the ideas come up and tells the group about the ideas. Clear, logical and persuasive stories help team participants bring their vision to others.

Stories, News & Mentions about SESSION

Session’s Stories on HackerNoon

Session's News & Mentions