One of our clients wants to FE log in as two different users at the same time, using one browser. I think this is only possible when using two different browser. IS there any workaround?
Background is this: We wrote a FE extension where user can login and update some of their data. One client is a kind of superuser/admin. He wants to compare and edit data of several users at once.
Authentication in TYPO3 is performed by cookie fe_typo_user and therefore it is not possible to have two users logged in at same time from same browser.
You may advise to use different browsers or virtual machines for your client.
As Viktor wrote - it's not possible. Here I should finish the answer.
Anyway... while you are creating your own plugin you can easily add 'simulate mode' using for an example custom cookies... Block schema is:
[IF isAdmin AND simulateMode == false] {
Display admin's version
} [ELSE] {
Display common user's version
}
You can go even farther and switch the admin to simulate some chosen 'common' user, anyway make sure that will not violate some privacy police.
Related
we tried to track email opens with google analytics and measurement protocol. We exactly followed instructions given in http://www.lunametrics.com/blog/2013/06/17/email-tracking-google-analytics/ and http://dyn.com/blog/tracking-email-opens-via-google-analytics/
The problem is that every email open is counted also as a session which is not correct. Can you give me any advice how we can track opens without recording sessions? Thank you
Every hit in GA always starts a session, so this is not possible. If you don't want it to appear in your normal profile, try setting a pageview with prefix so you can filter them out into a seperate View.
e.g.
/virtual/email-open
Then set up your filters.
Session begins with any interaction. Don't be sad, it is correct.
You can extend your data with some identifier like virtualpagname or whatever and than make segment or filter.
dp=mypage.com
dh=/emailing
dt=Email Gate
You can either use datasource parameter:
ds=email
https://developers.google.com/analytics/devguides/collection/analyticsjs/field-reference#dataSource
I am working with GWT / RequestFactory and a set of customer requirements regarding permissions. Let me explain a basic example:
Every user is assigned to a company. Every user should be able to edit company's core data - but only e.g contact information, website etc. Security-relevant ones like BIC/SWIFT, IBAN, Company name and so on can only be changed if the user has a certain permission XY.
So far so good, on the client side I can check the permissions and disable those fields the user is not allowed to edit. But what would be the most elegant way to ensure on the server side that those fields have not been set without permission?
My problem is that I cannot track changes on the server side. Having #PreAuthorize on every setter is not an option too, because it would end in an authorization-massacre in each and every entity.
At the moment I am following a workaround: every field that is secured / depends on a given permission is passed as an argument to the entity-method and is excluded from the proxy. That way, values cannot be set using the proxy and I can check in my server code if the user has permissions. If not, nothing happens. If user has permissions, I set the values manually. But that produces a lot of boilerplate-code and ugly method signatures because the number of values passed to the method could get large.
I hope you understand my issue. I'm looking forward for your opinions and tips. Thank you in advance.
Well, you can receive many answers (different each other), and all of them could be right, so, at the end is your call. Wait for others answers. I am going to give you the approach that I followed (and it worked pretty well). :D.
Under my opinion, the server should do less as possible, so keep the logic for allowing modify each param on the server I think it is not a scalable solution (if your system has 1M users modifying everything at the same time, will your server work fluent?). I prefer let the client do the job (like Roomba :D).
For solving that problem, in our system we implemented an Access Control List solution. You can store in your db, on each user entity, a list with granted permissions. So, when that information arrives to the client (after user's log in, for example), you can get them, and show the fields that he/she is allow to modify.
Something like:
if (canModifyPersonalDetails(user.getAcls(), ...) ) {
//show labels ...
}
if (canModifyBankDetails(user.getAcls(), ...) ) {
//show labels
}
You can not avoid server call for log in, so it is not a big deal send the extra information (think about the ACLs could be simple list of integers 0 means personal details, 1 bank details....).
If you are dealing with very compromised information and you prefer do some stuff on the server, in that case probably I'd set up a security level, when you are persisting/updating your proxy, I'd do something like:
if (isAllowForPersonalDetails(user.getSecurityCode()) {
//update the modified personal details
}
if (isAllowForBankDetails(user.getSecurityCode()) {
//update the modified bank details
}
user.update();
I am a big fan of clear User GUI's, and a very big fan of let the server free as much as possible, so I prefer the first option. But if you have constraints for modifying user entity in db, or you prefer do not modify your views, or any constraint with security, maybe the second option is the best one for you.
Hope that helps!
I am not 100% sure if this is as big an issue has I seem to think it is right now but I think I may of found an issue or at else an hole within the Inspect Element viewer within Chrome.
I was using (I have now changed my settings) hidden ID's to set a number of defaults, one was users levels, another was to make the user active by default.
However when I view these ID's within the inspect Element view and then changed the values, submitting the form would submit the NEW value to the server and not the value I had given it.
For Example:
I had something like the following within my code,
<input type="hidden" name="data[user][level][id]" value="1" id="MyID">
I then changed it within the Inspect view to,
<input type="hidden" name="data[user][level][id]" value="2" id="MyID">
Then I submitted the form and was surprised that the NEW value was submitted, I was always under the inpresion that hidden ID's where not changeable and the browser should only submit the default values held within.
I have now changed this to letting the database default to a basic user and then I can change the users setting has I want to. But in some cases this may not be an option, so I was hoping for an answer or some feedback about how to make this more safe.
Am I just a bit slow, are there better methods (different ones) to passing 'hidden' data from forms to the server?
I was thinking about maybe using JQuery to add the needed hidden fields to the forms once the user had selected / submitted the form, but i am not sure if this is 100% safe or even if its a good idea.
Any ideas / feedback are very welcome.....
Many Thanks,
Glenn.
I had the same problem passing the database data into a modal,the solution i know is to use jquery ajax to get the informations from the database requesting a file,adding them into variables and compare the variables
$.ajax({
url: "test.html",
context: document.body
}).done(function() {
$(this).addClass("done");
});
I used this code sample to do it.
Of course there are a few modifications to be done depending on your script
I found a better way of doing this, at lest in CakePHP. The CakePHP framework has inbuilt security calls. These in-built functions when added give you all sorts of stuff but the main reason I used them was to stop this sort of form tampering.
I am not 100% sure how it does this, but it adds a token to all forms and it checks to see if the form being submitted is right? Again not sure how the token works.
But here is the code I used ::
public function beforeFilter() {
$this->Auth->allow('index', 'SystemAccess');
$this->Security->blackHoleCallback = 'blackhole';
}
public function blackhole($type) {
$this->Auth->logout();
$this->Session->setFlash('Sorry a security issue has been detected, please try again or contact us for support.', 'default', array(), 'bad');
$this->redirect($this->Auth->redirect('/'));
}
Now I will add that the call the Auth logout I added to this for extra added security, as the user maybe have logged in on a system and it just not be them that is trying to do things that they should not.
Hope that helps others out!
But this is only a fix for when CakePHP is in use. I would take it that other frameworks would have their options but if your only using basic HTML? or a CMS like Drupal again there might be in built security.
Many Thanks
Glenn.
The only safe and best solution that I found for this issue is to check on the server side whether the user_id sent with the form is the same user_id logged in with or not.
Although using jquery is good idea, but, did not work with my case as am using data: $(this).serialize(),
However here's my code on the server side (Note, am using Laravel 5.4, but am sure it won't matter with your case)
if ($request->user_id != Auth::user()->id)
return json_encode("F**K YOU ! Don't Play Smart -_- !");
else
raw_material_category::create($request->all());
Hope this helped ;)
I am using web2py forms and i want to have some fields only visible to user (as fixed which cannot be edited). I tried making various combinations of editable, writeable, readonly but was of no use. I looked into web2py book too but that also seems insufficient. It would be great if someone can tell me how to do this.
You mean some fields visible to all visitors and some fields visible only if logged in?
If that's the case, then build your form conditionally:
form_fields = [
Field('pubfield'),
Field('pubfield2')
]
if auth.user: # This is true if the end-user is logged in and you're using the built-in auth
form_fields.append(Field('private_field'))
return dict(form=FORM(form_fields))
Unless you're not talking about logged in users, and just want to make the fields be visible, but not editable. Then, use writable=False like you tried, but I think you have to either use crud.create/crud.update or SQLFORM / SQLFORM.factory (the latter does not require a data model)
SQLFORM.factory(Field('my_readable_field', writable=False))
If you the form is based off of a database, you can use CRUD (you'll need to modify the settings for CRUD if you're not using authentication, so that CRUD forms are accessible)
crud.create(db.some_table)
or
SQLFORM(db.some_table)
I'm using Drupal 6.16: When a user creates an account on my site I have them select a category (ie children, youth, adult, etc). This is done with the select list box using the content_profile module. I have a content type that posts an announcement. In this content type is a check box that says 'email group'. Right now it does nothing, but what I would like for it to do is e-mail all the users that are associated with the group they chose when signing up for their account. If this will require extra code please be specific as I am not a strong php programmer.
Thanks for the help!!
msindle
There might be some module that do it exactly, but I don't think so.
I would have done it using few building blocks:
Retrieve the list of emails using Views - define a view that gives you the addresses according to a given group argument.
Use Rules module that will send an email notification after node is created.
Combine the two (this is the hard part) - insert the values from the view as the recipients for the email. You might be able to do it using PHP inside the Rule definition, plus view execution.
Try to accomplish it, and if you get into troubles, you are welcome to contact me via shushu.i#gmail.com
I would try http://drupal.org/project/subscriptions module + http://drupal.org/project/messaging module. You can set preferences for automatic subscribing to content type. Maybe Rules module can subscribe users automatically after creating or updating content_profile. Or maybe Rules can flag users after creating or updating content_profile and Subscription module could autosubscribe flagged users.