According to the Cypress best practices, I should avoid using my login UI before each test. I'm struggling to do this using Oracle APEX because it appears the login process requires a lot more than just username and password.
I have used chrome's tamper data tool and Jmeter to inspect the mechanics of the Oracle APEX login process and, essentially, the login process has 2 steps:
(1) the login page redirects to a login page with a valid session id in the URL, seeded with dozens of time-sensitive unique ids.
(2) Upon submitting your username and password, a POST request is made to /ords/wwv_flow.accept with the username, the password and several other time-sensitive unique identifiers.
It appears that APEX requires something similar to following for a successful login:
p_json : {"salt":"108222855956905007172773085768141257328","pageItems":{"itemsToSubmit":[{"n":"P101_USERNAME","v":"jsmith"},{"n":"P101_PASSWORD","v":"Password123"}],"protected":"unDCYO1qmj_OAwtyYNo_yA","rowVersion":""}},
p_flow_id : 4000250,
p_flow_step_id: 101,
p_instance: 6589106753596,
p_page_submission_id: 108222855…,
p_request : LOGIN,
p_reload_on_submit : A
All of these variables (besides the username and password) are available in the login page but to get them I'd have to visit the login UI, which is what I'm trying to avoid. Am I thinking about this the wrong way?
I believe this is the wrong approach. As for Unit testing you have to accept some degree of variability in terms of production vs. pre-production.
Saying the above I think you need to consider some more "normal" approach such as:
Change passwords in Pre-Prod.
Alternate Authentication Scheme.
Alternate Build Option(s) based on your needs.
I am not sure about these best practices you mention, but the session information you might pass along you testing must be created by APEX engine on the server-side.
There is no such way to bypass the login by just passing some parameters to the server other than a proper credentials information. What you can do, however, is implementing a custom authentication schema in APEX that would authenticate (and would create your session) by using some token or some other custom way, for i.e., checking the browser agent, IP address, environment, I don't know.
This custom authentication schema isn't related to unit-testing though.
Related
I'm building an eCommerce website for a personal project. It uses React for the front-end and a REST API running on django for the back-end. I want the user to be able to add items to a shopping cart and place an order without the need for an account.
For guest users, using a session/cookie to store info is great, but when it comes to logged in users, I would want to use the database to store items in a cart. That would require creating a user and giving them an auth token so they can perform necessary actions.
So should I use session/cookie authentication or is there a better way to achieve what I want using JWT?
Both approach can work very well. However, I am currently working on something similar and I would personally recommend the simpler option which is the classic session approach. JWT tokens can be harder to maintain and sometimes insecure if not done correctly. Also, JWT tokens will not persists between logins.
In both ways, I don't see why one would be better to create and maintain a cart except maybe that a session system can actually store the complete cart in the session itself. You can then implement sessions controllers at the API level.
ex: GET "https://{host}/api/cart" returns the items in the session's cart.
# Django session
request.session['cart_id'] = cartId
# JWT Tokens
jwt.encode({‘cart_id’: cartId} ...
little note.. It can be harder to setup the sessions if you are working on localhost for react and a remote server for your API. (The cookies are generally set per domain).
I am using JWT, and I think if you are using a database, you can create a generated JWTby user then store it in the database, you can control the availability of your jwt, in parameters, and I find the best way to secure your APIs, is to add the JWT token to the headers.
I would use Cognito authentication and integrate it with react and the backend api. It will help to manage the users outside the application.
If you’ll be hosting your application in AWS, Check out AWS Cognito, it’s an identity and a user pool service. Their free tier is quiet generous. That, together with AWS Amplify which is perfect for React, will give you out-of-the-box auth and user management.
I have developed a small application for submitting some data to database server(Oracle 11g). When we are reviewing security of this small application, we observed as follows:
1. We have deployed django with https and all secure configurations like Secure Cookie and Secure Session, No Cache, etc.
2. Using BURP tool for this sample review
3. We have created two different user in this system say Normal User and Admin User
4. Opened 2 browsers(Mozilla and IE 11), On mozilla we login with Admin user and captured session id using burp tool.
5. On second browser we login with Normal user and replaced session id Normal User with Admin User.
6. whoila......On second browser, I got Admin user access by just changing the session id
I have used default session backend for this application.
I would like to know whether this is flaw in django and how to resolve this issue..
Thanks in advance
This is an inherent risk of using session-based identification. It's called session hijacking, and if you search for that term you will find lots of information.
Mitigations generally have one of two goals: making it harder to steal the token, or making the damage less severe if it is stolen. In the former camp are techniques like using HTTPS and SESSION_COOKIE_HTTPONLY. In the latter are things like limiting the length of a valid session (SESSION_COOKIE_AGE). In the end, though, it's difficult or impossible to stop someone from impersonating another user if they get their token, since that's the very thing that establishes identity.
I am creating a saas, software as a service site with django.
Due to the project requirements the users are inside schemas/tenants, for that im using the fantastic django-tenant-schemas app, one user can have accounts inside different schemas (they share username and password) ... i want to let the user move throught the different schemas they are in more or less freely ... for that i have created a view where the user can select on what schema he wants to be on.
When i use an application wide cookie session that is when i have the cookie setting as ".domain.ext" (django documentation) that works fine but its NOT the behaviour we really want for our application.
What we really need is to be able to have different versions of the app on different browser tabs.
So we have to set the cookie configuration to "domain.ext", then everything breaks because the original view is on one tenant and the next view (where the just logged user really belongs) is inside other tenant then the old cookie is deleted.
So the question is how can i programmatically set the cookie correctly on the new view so the user that really belongs to that tenat is still authenticated.
Or is there any alternative approach we could use for that? Any examples?
EDIT TO CLARIFY as demanded:
Person A belongs to 2 schemas SH1 and SH2 on both of them he has the same username and password.
On every password change the password hash is replicated on all the schemas they belong to so they dont have to remember specific passwords or usernames.
When the person is logged on SH1 the url will be sh1.domain.com when he is logged on SH2 the url will be sh2.domain.com
So lets say the person is now logged on schema SH1, he decides to switch to schema SH2, to be able to do that i need the user to still been authenticated so that view has to be on the SH1 schema, but then its redirected to the new schema force authenticating the user but since the cookie is set as domain specific (default django behaviour) when the user lands on the next url sh1.domain.com/whatever the previous cookie is deleted and thus he has to log in again to be able to access.
If I'm understanding correctly, you want the ability to have the behavior of a cross-domain cookie, but without actually using a cross-domain cookie.
The immediate answer that comes to mind is "well, use a cross-domain cookie". This is pretty much the vanilla example of a situation where you'd want to use use a cross-domain cookie. Engineering a complex solution so that you can avoid using the simple solution never ends well :-) Unless there's some other constraint in play that you haven't revealed, I'd start by questioning whether you shouldn't just be doing this the easy way.
However, assuming there is a good reason (and, frankly, I'd be interested to know what that is), the problem you're going to face is that browser security is essentially trying to stop you doing exactly what you're proposing. You want to know, from domain SH2, whether something has happened to a cookie set on domain SH1. That's exactly the situation that cookie security policies are designed to prevent.
The only way you're going to be able to work around this is to have a third party that can share knowledge. When user A logs into SH1, you do password authentication as normal - but you also post a flag somewhere that says "User A is now on SH1". When A logs into SH2, you post the corresponding flag. If A goes back to SH1, you check against the central source of truth, discover that they're currently on SH2, and force a login.
You probably could do this by manipulating cookies and session keys, but I suspect an easier way would be to use an Authentication backend. What you'll be writing is an authentication backend that is very similar to Django's own backend - except that it will be making checks of cross-domain login status against the central source of truth.
How you implement that "source of truth" is up to you - an in memory cache, database table, or any other source of data will do. The key idea is that you're not trying to rewrite cookies so that the same cookie works on every site - you're keeping each site's cookies independent, but using Django's authentication infrastructure to keep the cookies synchronised as a user moves between domains.
I have used PHP SDK-4 for Facebook login in CakePHP 3 (beta version) which works fine.Now, I'm in need to fetch user data based on FB login and authenticate users. Am trying with Cake's Auth component. Initially, while trying to Auth users,
$this->Auth->setUser($user)
Got Error: Session was already started as we require session_start() for Facebook login. 1- Tried with enter link description here, and sessions [session_write_close()] etc..still it did not work. Could I get some shot on best way to authenticate users with Facebook login in site?
CakePHPs sessions are lazy started, that is, they are being started once your try to access the session in some way, and in case the session was started manually in beforehand, you'll receive that error, see Session::start().
You can easily workaround this by manually starting the session via CakePHP. The session object is available in the current request, so for example in your controller before using the SDK you could simply do something like
$this->request->session()->start();
and then the Facebook SDK should be able to pick it up.
As burzum already mentioned in the comments, the authentication should better be wrapped up in an authentication handler.
I would suggest having a look at HybridAuth, there's also a CakePHP plugin for seamless integration into CakePHPs auth mechanism, this might give you some ideas for a custom implemenation in case you need to use the v4 SDK, which isn't yet supported by HybridAuth.
I am working on a Perl Dancer web application that needs to accomplish two things in terms of authentication:
authenticate users based on Active Directory for access to the application
authenticate as the user to access a couple of .NET web services.
The application is being hosted as a CGI application by Apache on a Linux box, and I do not have much control over Apache's configuration.
Below is the workflow of the currently working application:
Display a login page to the user
When the user submits the form, use Authen::Simple::ActiveDirectory to verify the account is valid
Store the user's credentials using Dancer::Session::Cookie (encrypted cookies)
Display a search form to the user
When the user submits this form, use Authen::NTLM and SOAP::Lite to access the .NET services (similar to the example here) to perform a search
Display the results to the user
The handling of user credentials here concerns me, but I am generally new to web applications and authentication. For a small internal application, is this okay? If not, how do you suggest I improve this process? Like I said, the application as outlined above works, but I feel like it could/should be improved.
One (part of a) solution could be that you let your apache webserver handle the
authentication. You could use Kerberos for this.
So only permitted users can access your application. In that
case $ENV{REMOTE_USER} contains the username (e.g. foo.bar#MY.DOMAIN.COM).
If you need more information about the current user you can query your LDAP (containd in your Domain). I use a common (LDAP) user to get more information about the current user foo.bar#MY.DOMAIN.COM.
I know that this is only the fist part. I do not have experience useing/passing Kerberos tickets by SOAP. But if you mange to handle this, you have a clean SSO solution.
HTH
We do this in the Apache config. It requires something like the below. You'll need a read only password-less user to bind to Active Directory.
AuthName "Active Directory"
AuthType Basic
AuthBasicProvider ldap
AuthLDAPUrl ldap://server:389/OU=COMPANY,DC=COMPANY,DC=com?sAMAccountName,mail,name,extensionAttribute2,memberOf?base?(objectClass=user)
AuthzLDAPAuthoritative on
AuthLDAPBindDN "CN=ReadOnlyUser,OU=ServiceAccounts,OU=Users,OU=XXX,OU=COMPANY,DC=COMPANY,DC=com"
AuthLDAPGroupAttributeIsDN on
require valid-user