I am using ofbiz for an e-commerce site and I have recently migrated from EC2 type amazon servers to VPC type servers provided by Amazon.
After migrating I often see ofbiz asking for login credentials again and again before performing any task. In other words, I have to provide my credentials again and again to accomplish any single task.
Google couldn't help me with this neither the ofbiz forums, any hint if not the exact solution would also help.
This sort of problem often requires some research and testing, but I'd start with looking at session related issues like cookies (for plain HTTP) and HTTPS sessions, and also that the jsessionid is included in the URL when switching between HTTP and HTTPS.
It may be that something in the network is different between the plain EC2 and the private cloud and that is causing issues with maintaining the session. I don't know a lot about VPC on AWS, so can't comment on more detailed things to look into there.
Related
In Laravel Forge there's an option called Website Isolation, which some people also seem to mention as user isolation as well. I am not quite sure what it does and possible benefit for such functionality. It would be great if someone can explain this!
It also means you can assign different users to different sites on your server. You can give them SSH and SFTP access to a specific site without allowing them access to other sites on the same server. It also can prevent malicious code in one site from affecting another site on the same server if these sites have different users.
See https://blog.laravel.com/forge-user-isolation
I found out that one of the biggest advantages for using Website / User Isolation is that Laravel Forge will be then able to offer unique and independent nginx environment compared to other sites exist in the same server. Thus, in situations where it requires restarting an nginx or overloading, other sites in the server should work perfectly fine.
I am experienced in working with AWS but this is my first foray onto Google cloud and I am stuck on how to debug it properly. I am building a simple experimental setup, using Cloud Firestore to store some data and planning to do some small API functions to query it.
I am inputting my information from a Go app, which I built using the official SDK for Go. Everything builds fine, but when I run it I see nothing other than rpc error: code = PermissionDenied desc = Missing or insufficient permissions..
I have tried setting the authentication to open in the Firestore rules console (allow read, write: if true), but I still see the same error, so it seems to be an issue with the credentials I have generated rather than Firestore itself.
The credentials in question were generated in the main Google Cloud Console, under Service Accounts. I've saved it out as a JSON file and am loading this into the app via option.WithCredentialsFile() which is then passed into the NewFirestoreWriter() constructor.
It's far from obvious, to me at least, exactly how to configure the permissions on the Service Account as it seems to work quite differently from Amazon IAM. I was expecting to find a way to add on specific actions related to Firestore but I can't find anything at all like that once the service account is created. Under Permissions, it looks like I can associate other accounts with the service account, which seems to be the other way around to what I want to do. Or do I need to assume another identity once I have the service account in order to do anything, a la Amazon STS? Or am I barking up the wrong tree here?
I am running locally while I am playing with the apps, planning to think about deployment later.
I guess my questions are:
Should I be using a different form of credential when making programmatic writes to Firestore?
What permissions need to be on the credential that I am using?
How do the Google Service Account permissions interact with the Firestore access rules, or are they completely separate?
Thanks in advance for your help.
I finally worked out the answer. Turns out I was reading some of the screens too fast....
The programmatic approach with the credential was fine, but the service account setup was not.
In case anyone else has a similar issue, the fix was to:
Go to "Access" under IAM (NOT identity). Coming from AWS this confused me a little because I was expecting roles to be a sublevel to identity rather than a seperate level
Click the Edit button next to the service account
Add the Cloud Datastore User and Cloud Datastore Owner roles (I'll work on trimming down permissions now it's working!). This confused me particularly because I was looking for "Firestore" or "Cloud Firestore", and there is the very similarly named "Cloud Filestore" which tripped me up.
After a few seconds, it started working.
According to https://cloud.google.com/firestore/docs/reference/libraries?_ga=2.87049368.-1865513281.1592929406#server_client_libraries,
In this environment, requests are not evaluated against your Firestore security rules
So I reset my access permissions in Firebase back to allow read, write: if false.
My Heroku-app is being used by other people, on other websites then mine.
Is there a way that only my site can use the app?
I have a small site so i use a free account, this way my free "dynos" are gone very quick.
You have some options...
If your app or api is being used by javascript web apps in the browser then setting a CORS heading specifying your top level domain should do the trick.
If your app or api is being consumed by other servers or non-browser based processes then specifying an authentication process such as http basic (user/password) should restrict access to the set of clients that you control. If your service is successful then congratulations! Maybe you should scale up and start charging?
It seems like your goal is to stay in the free tier at Heroku.
Heroku starts your dynos triggered by the request coming in on their router mesh. This means every authentication or blocking technique inside your application will still lead to the dynos being started (that includes CORS).
Heroku itself doesn't give you configuration for their routing in the free/low-price tiers. If you pay for it, there is private spaces.
One possible solution is to have another layer over your app that does the authentication.
For example this could be:
cloudflare
Amazon CloudFront (not sure, with the Web Application Firewall)
other CDN
These will likely have a free tier that's enough for you, but also be rather complex to setup for a beginner.
I hope I could help you a little
Sorry for any silly question but I am just about to learn about the web.
I have an application (called OFBench) that uses the Selenium library to simulate user browsing behavior of website. The web site is built on the Ofbiz template (nothing more added). I have 2 EC2 servers on Amazon Web Service that running the ofbiz website template and one client on my laptop generating workload (simulating users on website) for the 2 servers. The browser instance used is firefox.
The 2 servers are sit behind a Elastic Load balancer (ELB) and the ELB is configured with application based session stickiness. When the application simulated a login and then do a "Home" request (clicking the home link on the website) the login state is gone which causes following requests fail. Looks like the ofbiz website does not has session cookie. I am not sure where the problem is, but I need to know how session is handled in ofbiz ? Where does it stored ?
I observed that when I open the home page of the ofbiz website there is a session created (reported by server: xxxxxxx.jvm1 generated) and sessions are generated quite often. Not sure why it is the case. I though only when you login or putting stuff in shopping basket should the session being created.
Thank you very much for answering my question !
Just for the benefits of anyone who having the similar problem. When setting up application based session stickiness with ELB you need to give the name of session that actually generated by your web application, in my case, I saw that there are two kinds of session (JSESSIONID, Ofbiz,Visitor) I used JSESSIONID as session cookieName in ELB and the login state is maintained. Please do correct me if there is anything that might goes wrong. Or anything that I did is happen to work. Many thanks
I'm using the role-based caching feature for a windows azure web role.
Configured as co-located. I've followed the steps given by windows azure docs for caching (preview). I get the following error:
ErrorCode <ERRCA0017>:SubStatus<ES0006>:There is a temporary failure.
Please retry later. (One or more specified cache servers are
unavailable, which could be caused by busy network or servers. For
on-premises cache clusters, also verify the following conditions.
Ensure that security permission has been granted for this client
account, and check that the AppFabric Caching Service is allowed
through the firewall on all cache hosts. Also the MaxBufferSize on the
server must be greater than or equal to the serialized object size
sent from the client.). Additional Information : The client was trying
to communicate with the server: net.tcp://127.255.0.4:20010/.
I'm running everything as localhost, using the local development storage, my cache client is in the same role as the server. Changed many configuration attributes, but I always get that excpection or similar like "cannot connect to tcp....".
I'd appreciate some help. Thanks.
There are couple of things which could go wrong with your application.
Very first thing to make sure that you have SDK 1.7 in your machine even with Windows Azure Caching Services and then verify that you have reference set from Windows Azure Cache (not from Windows Server App Fabric SDK). I have seen such misconfiguration in past which lead to such errors.
Now have you changed your dataCacheClient, identifier to your ROLE Name as described in the documentation link here. If you follow the documentation as described to you should not hit any error so for the sake of checking what could be wrong, you can create exact same application as described in this link and see if that works or not.
To get more details error, please be sure to increase the DataCacheFactoryConfiguration.ChannelOpenTimeout value to longer i.e. 2 minutes then default 20 seconds as described here. This step will help you to get details about inner exception which may lead to actual root cause to your problem.
We use Azure co-located caching (not in preview anymore) as our session backer and have fairly regular outages. About once a month.
We tried using the Enterprise library Transient Fault Handling but our instances still hang when caching experiences problems. I think that the transient fault code would work for data caching, but for session backing there is some activity closer to the metal that we can't seem to code against.
The error codes have become more informative over the last year and go something like...
ErrorCode:SubStatus:The request timed out..
Additional Information : The client was trying to communicate with the
server: net.tcp://10.xx.xxx.xx:xxxxx/.
Our best guess so far from experimenting and MS support is that each, or at least one co-located cache role/instance needs to know about all the other instance's IPs, since Azure can destroy and re-up instances whenever they want, this sometimes fails to update the dependent instances. This is secret sauce for Azure, but it is not a secret when our site goes down. I'm looking for any more information on this and to see how others are working around this issue.
One possible work-around. One of our talented platform administrators found that resetting IIS on the instances and scaling up two more instances seem to help the problem. This makes sense to me because it gives caching another chance to gather all the required info about the other instances. This is NOT CONFIRMED to solve the problem but if we repeat this during the next outage it could be a valid work around.